Motley says: "I am a developer - I don't test. Testing is for the test team."
Summary
Motley: Unit testing is the test team's job! I am not paid to write tests.
Maven: White box (unit) tests help with code quality and give you confidence to change your code.
______________________________
[Context: During a previous conversation about debugging, Motley stated that he doesn't do unit testing]
Motley: Yeah, that's what I said: unit testing is the test team's job! I am not paid to write tests.
Maven: Did you know that unit testing is a developer technique with one of the biggest returns on investment?
Motley: Great. But it's still not my job. We hire a test team. They test. That's what they do.
Maven: But does the test team know the code the way you do? Unit tests need to be white box tests - they exercise as many code paths as possible - ideally, all - and require knowledge of the code.
Motley: Testers are technical people - they can figure it out.
Maven: But, they have a lot of other stuff to do. The test team has to do performance testing, stress testing, integration testing, platform testing, and of course, the all-important testing of real customer scenarios. Do you think they have time to find all those trivial little bugs that you should have caught before check-in? The answer is NO! The have expectations that developers write high quality code. They then do the validation of the code with test scenarios that would be difficult for developers without a full infrastructure to test.
Motley: They're also the reason why our ship dates are often missed!
Maven: Only because the developers are not doing their job with unit testing. You need to do a root-cause analysis on why we have these long "stabilization" cycles. We should not be stabilizing anything! As of our code complete milestone the code should be stable. The Test team validates on the black box level - without having knowledge of the code - to ensure integrated scenarios work properly.
Motley: So you're saying that developers need to write test code??? Bah!
Maven: YES! Try it on the unit level. In the object-oriented world, a unit is often a class. Write a set of tests using a unit test framework that exercises the contracts of your methods. Run them as often as possible - ideally, after every code change. By having tests in place, you have the confidence to change your code without breaking anything. Plus, you can generate code coverage numbers to help validate the thoroughness of your tests. The test team will thank you because now they can focus on their real jobs and not cleaning up after the developers. The test team also gets some nice sample code that helps them learn more about your APIs.
Motley: Sounds like lots of benefits to have unit tests, but I am still not totally convinced. If I take care in writing my code and ensure it's bug-free, test can still concentrate on doing their real jobs.
Maven: But you can't be sure your code has minimal bugs until you test it! Honestly, if I could get devs to add one technique to their quality arsenal, it would be unit testing.
Motley: Tell you what: I'll give this thing a try. However, if I don't get positive feedback from the test team that it is helping, I'm going to return to writing real code and let them figure out if my stuff works.
Maven: I'm good with that. I think you'll come out a winner! In the future we'll talk about this idea of contracts and code coverage, but start with some basic tests.
Motley: I really look forward to that conversation - kind of like a cat looks forward to being neutered.
______________________________
Maven's Pointer: These days, Microsoft hires testers that are just as technical as developers - they just have a different role. However, since developers know the code in detail, they need to be the ones to test the details. The test team can validate the code on a higher-level to ensure integrated scenarios function correctly. By combining the test responsibilities, we ship sooner and with higher quality.
Maven's Resources: Pragmatic Unit Testing in C# with NUnit, by Andy Hunt and Dave Thomas, Pragmatic Bookshelf, ISBN: 0977616673, 2007.
