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 (I'd 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 it's a great technique and worth more community/industry awareness.

 

Who uses TDD? How has it worked for you? Who doesn't 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 I'm 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 I'd probably be an advanced beginner. Though thats a pretty broad scope.

[mskeel]

I sense an influx of questions...

Hahaha...I think you're right. That's 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 don't 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 don't do it. What makes me really nervous is that the probability that I'll have to work with a person who doesn't do the simplest things to make their code better is extremely high. So really, my intentions here are greedy. I don't want to get stuck on a project that doesn't unit test so I'm 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 weren't 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 don't 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 don't 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 haven't 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? I've used simple mocks (not dynamic mocks) to inject data into classes, but I've 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?

 

I'm just curious to hear what other people are doing and using.

[Malfunction]

i've 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´m pretty interesting in starting doing TDD, but right now I have a huge class hierarchy to mantain and evolve, most doing CRUD operations. So I have lots of stored procedures calls and too much data dependencies.

I tried to play a little with unit testing but I couldn't find an easy way to do it. I heard mock objects would solve my problem, but I still didnt get into it.

 

I´d be glad if anyone could point me in the right direction. :confused:

[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 can't 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, you'll want to mock whatever you either don't have control over or can't 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 doesn't 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 shouldn't 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 doesn't have unit tests and want to add them in, check out this book. I got it a few months ago but haven't had time to really read it yet. It defines legacy code as any code that doesn't have a unit test. The point of the book is how you add tests to code that doesn't currently have tests.

 

-ner

[Cassio]

Thanks for the information, mskeel.

The problem is, the system I'm working in is mostly doing CRUD operations. Its a big project but the objetcs don't 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!