Do you use Unit Testing

[sde]

Do you use unit testing? We're in the process of implementing this at work and I just wanted to get an idea if anyone here uses it.

I read that once you start using it, you find it difficult to code a project without it. Is that true? Is it something that becomes a key part of your development process? Would it make sense to use even on small project?

I just want to see what other people think on this subject.

[jeffro]

Yes, we use JUnit. Tho I have to admit it the first time we tried it, it was more of an afterthought. The second time we started with it from the ground up. It was actually ant ant target so everything was automated, we had a script on the server that would check out the days latest code, build, checkstyle, then run the junit tests. It was pretty slick and it caught alot of logic errors that weren't readily apparent, but I really don't see alot of use for it unless it is a large project. IMHO.

[technobard]

Testing is for amateurs. We just put it in production and let the users work out the kinks.

The development teams I support do use unit testing as an integrated part of the development process. It does make the most sense for larger projects, where you actually have "units" to test, but obviously some sort of testing would benefit every project. Just my 2.5 cents.

[redhead]

Hell, if it compiles it will run right ??

But yes, when I was involved in kernel development, we used unit testing, it makes it easier to zero in on where the problem is, but it also helps develop true bounderies the different scopes of the project should be held within.
Which in C++ usualy woudl be your classes and namespaces.. But for C, you realy need to be strict about it.

[jiminoc]

Unit Testing is best for projects that will be expected to be maintained and added on to over the course of time. If you're doing a small set of scripts for someone's website and your code is 3% of the total codebase, and they want it done yesterday then you sacrifice good design for speed.

Test Driven Development works best if you actually start with the test, no code until you have a failing test. At this point you're coding from the outside in, you're creating your perfect API. Whats the easiest way you can use this class?

Having tests allows you to do one of the most important aspect of TDD which is refactoring. How can you refactor (change the internals of a program without affecting the externals) a program safely without knowing your changes didn't break something that relied on what you just removed?

When working on a team that shares the codebase, what makes sense to one person makes no sense to another, having a unit test backs up your thought process. If a developer comes to your code, they can look at the tests first to see what its supposed to do and then safely make they're changes and run the tests to see if anything fails. If a test fails, you'll know right away that it was your change.

The problem with only having unit tests on a timer is that you don't get the immediate feedback. If you couple constant unit testing as you refactor WITH automated running of the tests you should be ok.

Unit Tests allow you to program for today and re-design tomorrow which is somewhat a contradiction of normal life where you try and design everything perfect from the start, but have you EVER done something completely perfect the first time? Have requirements ever changed on you once you got your great design in place? This is the benefit of unit tests...

With tests you can come back to a piece of code that you know won't scale in the future and modify it safely with refactoring techniques... maybe move it to its own method, or make it a class of its own, etc... all without changing how the overall program outputs data


you'll also find that you name things better which requires less comments to know whats going on.

For example if you're coding the usual way you'll probably want to write the function declaration quick and get to coding the good stuff, so you might call function...
// get some xml string data to use in this function
function getString()

when doing TDD you're testing first so you'll most likely pick a name that is more meaningful to what its doing such as $test->getXMLDataStringFromFile()

now you don't even need a comment, obviously you can do that without TDD but coming from the outside in makes it easier.

k, rant over

[ChefFrank]

Wow! How things have changed!

I am very 'Old School' when it comes to coding and intergration. I always used a 'top-down structured' approch, but then again, I always used procedural languages, rather than OOLs. Top-down meant, you wrote the top level procedures first, and any lower level procedures were 'stubs' either returning a dummy value, or would print something like "Module X called". When the top level was done, I would work on the next level, using the same stub techinque until, eventually, the entire program was done. Unit testing was done with a 'best guess' approch to creating data sets, or, when things got more sophisticated, automated testing programs (I designed and wrote a kewl language back in 1988 called "Jaberwocky" that produced test data sets based on the DDL for all input data structures. I modified it about 1992 to test both client and server code. It was able to generate incorrect data on occasion, to test error handling, and could actually be used for stress testing creating a mix of server requests, based on estimated proportion of each type of request that would actually be processed. My proof of concept was designing a major financial system from the ground up - including hardware. My little 'science project' was able to project required hardware, comm lines, etc. for full roll out from a very miniscule pilot system. I was able to predict almost exactly (I was 5% high) worst-case scenarios (about 100,000 TPS) and saved my client some mega-bucks by keeping them from buying unnecessary hardware - this was in the time of "Big Iron" and we were talking $1.5 - $2 million per unit. My management actually had to cancel the order for this stuff because they didn't believe my numbers. As you can suppose, I'm big into statistics. )

A good design, with good specs, saves a lot of $$$$ - I've seen some projects be delayed for weeks because the specs were ambiguous - a module was to return an integer value, and was coded to return a string value. The specs said "Module Y will return the value of .....". The caller thought 'integer' and the sender thought 'string' (it should have been a string, BTW). To digress, Fred Brooks, in "The Mythical Man-Month", talks about a programmer that got called because a system failed on the first night of production. He looks at the data, and saw an "&" in a field that was being tested - no 'special characters' allowed. He eliminated that record from the input stream and reran the program - which failed again with the same error - another "&". He looked at the input queue, and found that almost all input records had an "&" in them. He called the system designer (this was 3am) and asked about this - "You told me that there are no special characters in this field in your input - what's going on?" The designer said "There's nothing special about ampersands - we use them all the time!"

Unit testing is the biggest hurdle to make a project work. Most programmers will only test 'good' cases - the errors will fall out by themselves. I have seen several projects that looked good until it went into production, and then found major errors in code because exceptions were not thoroughly tested. One of the techniques we used to use (and I think is part of the Use-Case methodology) is to never test your own code - work with a 'code buddy' - you test his/her code and they test yours.

In my experience, probably about 95% of project delays would have been eliminated by good structured coding and unit testing. In general, 1 hr of unit testing, saves 10 hrs of delay. Of course, I'm looking at things in retrospect on several levels: coder, system archetect, programming manager and project manager.

The BIGGEST problem I've encountered have been MY managers who equated testing time with wasted money - the 'it compiled - it works' syndrome. Long term, my strategies worked and ended up being more cost-effective - which is why I'm retired already, and my managers are still working.

Wanna talk about testing stragegies? Drop me a line.

Frank

[DJMaze]

What i use is an special debug window.
All my important code has printf() commands inside a

PHP Code:

#ifdef DEBUG 


On execution of my WinMain i call AllocConsole()
http://windowssdk.msdn.microsoft.com...locconsole.asp

This way i can output data to check if the function works properly.
So mainly i don't use seperate unit testing