Test Driven Development

[mskeel]

To me, it seems like we have a full mix of regular users of this forum: a few true experts, a handful of proficient developers (Id put myself in this group), a very healthy population of advanced beginners, and the always present n00bs.

Considering the crowd, I just wanted to raise some awareness about Test Drive Development and unit testing because it is rarely mentioned on this board. Unit tests could be the next big step for an advanced beginner on the road to proficiency or likewise for a proficient programmer on the road to becoming a true expert. I think its a great technique and worth more community/industry awareness.

Who uses TDD? How has it worked for you? Who doesnt and why not? What tools/techniques/strategies do you use to help write/run tests?

Post your war stories and questions about TDD here.

 

[snarfblam]

So, mskeel, which category do I fall into? I guess Im not a true expert and never will be because I program purely for hobby and have no experience in the professional aspects of programming (team programming, testing, company standards, etc.).

 

[Cags]

I sense an influx of questions from people wishing to know which bracket they are in, lol. I supposed Id probably be an advanced beginner. Though thats a pretty broad scope.

 

[mskeel]

I sense an influx of questions...

Hahaha...I think youre right. Thats ok though. My "categories" are loosely based on the Dreyfus Model of Skills Acquisition. Check out this link for a full bulleted description of each level. It is important to note that professional level development does not make one an expert.

This is all about raising awareness for unit testing and encouraging folks who dont to pick it up and give it a try; and for those who do, to ask questions they might have or give advice. Unit testing is such an easy way to improve your code that it shocks me how many people dont do it. What makes me really nervous is that the probability that Ill have to work with a person who doesnt do the simplest things to make their code better is extremely high. So really, my intentions here are greedy. I dont want to get stuck on a project that doesnt unit test so Im trying to get everyone out there to use it or at least become aware of it so they can make a change in their work (or school...this is something I picked up outside of school and I wish I had known about when I had a midnight deadline and things "just werent working" as I was desperately making sweeping changes to my code under the gun...)

VS2005 (standard at least) ships with a test harness, the object test bench, which gets the job done. I can highly recommend NUnit and TestDriven.net as alternatives. Personally, I dont like the OTB very much at all. There are other alternatives to these listed, but this is what I have used and can comment on.

Why dont you unit test?

 

[PlausiblyDamp]

Since I started using Unit Tests the amount of problems that no longer appear when revising old code - run tests and all pass, make the changes, run tests again. If everything lights up green then you havent introduced any new bugs by tidying up old code.
It gives an enourmous amount of confidence when attempting to refactor old code to be able to check that nothing has been broken.

Additionally bug fixing is easier when you write a test that demonstrates the failure - once the bug is fixed the test is green (as are all the others) therefore job is done.

 

[mskeel]

Does anyone use Mock Objects exclusively for their unit tests or does everyone mostly use assertions? Ive used simple mocks (not dynamic mocks) to inject data into classes, but Ive always used assertions to test the classes.

What about GUI testing? Has anyone tried NUnitForms or are recorders the way most people do GUI testing?

Im just curious to hear what other people are doing and using.

 

[Malfunction]

ive never been responsible for gui programming but i do know people who are using jfcunit and really like it.

i usually test communication and persistance layer using mock objects.

my skill is... i dunno. not a guru but surely not a noob either. i like to scratch the surface but tend to not stick with one technology long enough to become an expert.

 

[Cassio]

I

 

[mskeel]

Every unit test you write should be a discrete test that gives a predictable, repeatable result every time. Say you are testing a data structure and you have a special constructor that will preload the structure with information from a remote database. Because each unit test should be written so that it will produce predictable results every time, you cant use an actual remote database in your unit test. Instead, you use a mock object that essentially spoofs a remote database. Now, you can have your mock database do things like return a null connection, send good data, send no data, or reject a request all without having to set up an actual database to do that for you. This happens at the class level as well as the module level. Generally, youll want to mock whatever you either dont have control over or cant duplicate in an isolated instance (file access is another example). Keep in mind that you may need to do some redesign work to take advantage of mocks objects.

In general, brining a project up to unit testing speed is pretty easy. First, get NCover (you might also want the explorer) to help you see what you are hitting and missing as you add tests. Next, find a class that is relatively isolated -- something that doesnt rely on a lot of other classes or outside projects. Then choose a method in that class and write a test for it. Now run the test and check your code coverage with NCover to make sure you flexed everything in the method you are testing. When you get 100% (or hit everything you can legitimately hit) and your test is green, choose another method/constructor and repeat. Generally, you shouldnt bother with simple properties -- they are pretty direct and easy such that you could consider it a waste of time to write a test for them.

 

[Nerseus]

@Cassio:
If you have existing code that doesnt have unit tests and want to add them in, check out this book. I got it a few months ago but havent had time to really read it yet. It defines legacy code as any code that doesnt have a unit test. The point of the book is how you add tests to code that doesnt currently have tests.

-ner

 

[Cassio]

Thanks for the information, mskeel.
The problem is, the system Im working in is mostly doing CRUD operations. Its a big project but the objetcs dont have much logic inside them. Most of the errors we get is related to the database or the layer responsible for the object-relational mapping. You know, maybe the DBA removed a stored procedure parameter and forgot to tell me.
So, it would be nice to test against a real database (not the production database, of course). How do you guys test database stuff, like stored procedures?


Nerseus, I will take a look at that. Thanks!