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
Wohoo...
The ultimative Football Screen for Geeks. watch the WM in an ASCII Stream.
just type in your command window "telnet diego.ascii-wm.net 2006" and press enter.
Freaking cool stuff. if you want to know more about that austrian students project, go to their website at www.ascii-wm.net
_ajjaa
_Q???4Qf
_,...,_ ) a/]QQb
.'@/~~~\@'. jQQba
//~~\___/~~\\ _, .?QQ#[ _
|@\__/@@@\__/@| ]m _.7 "asLaas_a/
|@/ \@@@/ \@| , ,\J#L -!4Wba
\\__/~~~\__// [aL[ \ \jmm jP
'.@\___/@.' ,b#'"[ \jmmmmm _P.
`"""""` a##' "4P#mmm# _ya
_P !4####m ?]aa/
/' aaJ#U###m# 4QP'
' aa,/4!44! '
jf _'jQQQQyb7b /
'. '.QQQQ4QQPb )?
QQQ'QQP?' jg/ f
_yQP']QQb aa
a#W?'..QQQQ?)? ?'
"##' _jQQP'
.j? [ jQQ'
aJ jmaaX#L???
? am'
_QjQQQ/
)QQQP?
4QQQ/
so, whats WMIC?
I think you know about WMI. the Windows Management Instrumentation is an System from Windows, where you can access the most of the properties of windows.
And WMIC? thats an Command line utility that comes with windows XP and up to query this stuff.
It's pretty amazing, how they managed to port code that needs plenty of lines in vbscript or c# into one line. cool.
I tried that tool for my IIS helper. did'nt work , but find some nice references about that tool.
First, try c:\> WMIC /?
here, you find a list of all commands.
a little bit more explained in the MSDN Documentation
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wmisdk/wmi/setting_namespace_security_with_the_wmi_control.asp
If you have some time, watch the webcast about that tool
http://support.microsoft.com/servicedesks/webcasts/en/wc072402/wct072402.asp
Also theres a cool list of examples at Handler's Diary
http://isc.sans.org/diary.php?storyid=1229&rss
Thats pretty all of what you need to start. if you need help about how to configure security, remote machine and so on, refer to WMI.
and you want to know, what i tried?
C:\>wmic /TRACE:ON /NAMESPACE:\\root\MicrosoftIISv2 PATH IIsApplicationPool CALL Recycle
This should cycle thru all of the appPools and Recycle them. but it don't work. allways comes with an "The parameters provided for the method are not valid.". and i dunno why. so lets try other things.
Jon Galloway posted, that you should avoid using the iisreset since it does a complete restart of the iis.
i agree with him, also have some more points
- it takes all sites offline for a short time
- it takes very long sometimes
- it devalidates the complete cache (on some changes its just nice to have the cached stuff from bevore)
- it detaches the debuggers
- it forces a recompile for the most dll in the web app.
I know, sometimes its needed. since you want a "clean" start of the app, or you have some strange stuff going on. but most times, its not needed.
so, we want a fast and easy way to do that.
If you ever look into the api of iis, you'll propably find 3 types.
- do the iisreset. sometimes you need it
- do an asp Reload
- Unload the App Pools (on win2k3)
the first is clear. run iisreset.exe.
The second one is the same as touching the we.config or global.asax. the FileWatcher there sets a flag in the iis, that on next request, it shuts the app down and starts it again. why not set the flag yourself?
The third one is just to unload the app pools from the ram. so they get startet again.
The Tool:
This is a simple .net 2.0 tool that i done for my division. i removed all extra features, so it just have the iis tools in it and some not needed code. it also has in my test version the possibility to do that remote. but have some bugs in it.
Also this tool is for win2k3. the app pool command will fail with an error message at winxp or 2k. and it needs .net 2.0. the app also works at vista, when you install the iis6 comptibility stuff.
The Features:
you get an small icon in the taskbar. right click on it, you have the 3 commands to execute.
after it has completed the command, it shows you the result. (e.g. how much app pools it unloaded. so you see, if it failed)
- Reset IIS: does the iisreset exe thingie.
- the Good:
- does really restart the iis. so all is clean afterwards
- the Bad:
- as listed up there, many things
- Unload AppPools: goes thru all the app pools and unloads them
- the Good:
- really unloads the App pools from memory. so also the inproc cache is cleared
- the Bad:
- takes sometimes long (specially when your code is waiting for timeouts)
- clear the inproc cache
- works always (except when the iis stops responding^^)
- forces a recompile and reload of the dll's
- Force IIS Asp Reload: Sets the flag, that you can also do by touching the web.config
- the Good:
- freaking fast (since just making an flag)
- the dll's keep loaded in memory
- the cache stays the same
- keeps debugger attached (so you can also catch the appStart events) (yeh, somtimes it looses them, but thats seldom)
- the Bad:
- the action is done on next request. (not really bad, but you should know that. e.g. the appShutdown events are then fired)
- the cache stays the same
- wrong loaded stuff in cache, dll, ... are staying
now, its much easier for me to do that stuff. have some ideas for extension. if you also have some, just post them.
Also, this is really just an "because its actual" post of the tool. not a real version that should be wide distributed.
Hope that helps you.