chris' dev Tidbits

Just read the post from Karl Seguin, that he now starts to learn TDD.

That’s an task, that I cannot follow. TDD is nothing you have to learn long time… neither it is a big change to your Development Process.

These post will describe, how to easy start with TDD, without the heavy stuff of all that “be agile, do your tests for everything”,.. and so on. If you are new to that, you don’t need to jump in the middle of the hot soup. Start slurping from the colder side…if you just want an short summary, read the conclusio at the bottom.

Test Driven Development just means, that you write test first, program later.

But this is done, when you write a single test, that just checks for example that the Response of your command line program is 0 (so executed with no error). Yep. Maybe that is nothing that helps you that much, or test the real important stuff of your program. But that’s basically an TDD.

So, why is everyone speaking of extensive unit tests and TDD?

Yep, nearly everywhere where you read about unit testing is speaking of TDD and write an unit test for all things you have. And this is also TDD, if you write this before. But its an more extended version. I speak in that case of Extensive Whitebox testing (EWT) e.g. TDEWT (test driven EWT, Since you can also write the tests afterwards).

White Box & Black Box testing

these differences are easy. Black box testing is, when you treat your Program as an Black (unknown) box, and make the tests as you were an normal user of your product (clicking thru the website, testing your Webservice, running your program). White box testing is, if you need to know your class structure to do the tests. (testing one of your components, mock up objects and so on). You can also treat it as Blackbox testing if you just testing the public API of your Component.

There’s a really nice Post about Black and White Boxes from Tyner BlainSoftware Testing Series: Black Box vs White Box Testing

How easy is it to start TDD?

so, you’re new to TDD, and someone say, you should/have/want to do it. How to start?

That’s really easy. For someone new to TDD and with their own Project (if your project already have some unit tests, you should maybe go on with them…) I would recommend to make some Black Box testing. Since they are much easier (most times e.g. in the beginning) and also more useful for the short time. To write good Unit tests, you need some experience writing them. Else you have to change them too often, since your test context has changed (added some parameters etc…) The first of these is simply, if it’s working (e.g. if your program starts, if it execute without error, if you can request your webpage without error,..) There are also some frameworks outside for these testing’s. And when you write such an test, before you write your program, it’s already TDD. If you just develop an component for your company, you can also start with make one test, that test the main process of that. It’s pretty the same.

That’s all?

eh, no. not really. You cannot ran now to your chef and say “We now implemented the latest trend and have changed our Development Process to TDD”. This is just the first step to start, and the basic thinking of TDD. Test first, develop later. That you stay just with one test, that make just the easiest test is allowed, but not the way it will be usefull to your development. and this is what we want to get from that. Not just that we can say, we have that.

What’s next?

Write more tests. I prefer much more that you think of, what is your important part and start there making blackbox tests, and not come from the other side. Especially when you implement that in an existing environment (so no TDD). Get slowly into Unit testing, think of useful abstraction, and definition of your components to the tests, and that all API’s could be changed in the future.

But all say, we need 100% Code coverage. This is far away from that…

the nearly 100% coverage is an double bladed knife. Yep, if you make some mistakes in implementing changes, you’ll get an error right after you tested it. But nearly all wanted changes you do, needs also changes in the unit tests. And that takes time.

I recently read some statistics about companies, implementing an nearly 100% code coverage, and they have 60% of their code written in unit tests and use nearly the half of the time implementing and maintain that.

I know, that there can be business critical applications, that are not allowed to fail anywhere. So here I see the request for 100% coverage. But for the normal program, or for an team that is just starting with TDD, I don’t think, that this is feasible. You put so much work in there, with not that much reward. It’s much more useful to write tests, that check your primary business and go deeper and deeper with time. So you have a pretty fast reward on small work for your testing. No one would start with making an Picasso at the first try. You start with some easy painting and learning.

Conclusio

Start with one test after the other. Think of what will be useful and your most important test (most time Blackbox testing). There’s no need to have an extreme high code coverage in the first implementation. The important part is, that it helps you fast, and identifying some big mistakes fast, and not when you tell your test team to make an “full tested ok”-test

A note to the geeks

“yey, what the hell you writing here? You are so an idiot”. Okay, maybe I’ll exaggerate that. But I’ll know, some of you thinking that is bullshit. But see it from the small guy. Some of your managers telling you “hey, the geeks say, use TDD. So do that now.”. or you heard about it yourself and want to implement it for the next projects. The most times in the normal programmer live there is no place to make from one day to the other 50% of the time unit tests (and definitely more time in the beginning when you learn it). Give them an easy, fast start in doing so, and the acceptance of it will be much faster and wider. I Appreciate critics, and will answer them. Or maybe write an followup.

p.s: this post is published with Word 2007. pretty cool