Software and People

Euxx writes I just complete over thousand lines of new code. Now it is probably ready for testing

Wow. I can't imagine running 10 or 100 lines of fresh code without having tested any of it, let alone 1000. I'd also hate to think how it is designed if there really is no way to test individual bits of this 1000 line monster.


Heh. You probably meant that link to point to here instead of your own blog...

Yes, there are people who still write loads of code and test afterwards, usually because someone forces them to. I doubt that species will vanish anytime soon :)

Strangely enough, I did link to there, but foolishly I had put an extra quote before the href so it ignored the URL. Fixed now - sorry.
As for the comment about being "forced" to code without testing, I can't really believe that.

Sure I have worked for people who thought testing was a separate phase, and wouldn't allow time for it in development plans, but even in these cases I unit test my own code (as part of design and implementation) because I know it helps me go faster and produce code with fewer bugs for the "real" testers.

How might someone who wants to unit test their code be "forced" not to, except maybe by disabling the compiler ?

Hmm. I don't believe that either. I meant to say something else...

While nobody is surely forced to code without (unit)testing for long periods of time, many organisations may well be encouraging such behavior by putting pressure on the developer from the project manager's direction.

Think "Frank, how can you spend 4 hours on this task while John does it under 3 hours? We're supposed to move to Testing already tomorrow."
...where John doesn't test at all and spends a whole day in the Testing phase fixing all those nasty defects that Frank's (whose code passed with flying colors in the Testing phase) tests caught early on.

I'm only just getting started attempting to get unit testing into this company. The idea of testing here is that a salesperson or instructor (who will be selling or teaching the product) sits down with it for a few hours and takes it for a spin. Of course programmers test their creations before releasing it to these people, but not usually before there's a complete unit of work coded. In fact, I'm finding bugs in code that's a year old or more that were never discovered because the code hadn't been used ever... I'm hoping to get some more testing in by simply doing it myself and showing that testing while coding will yield overall more stable code.
I always reckon that one of the most important things to remember about unit testing is that it is mostly of use to the programmer. Although I make my unit test code available to my clients, they usually don't even look at it, let alone run any of it. The benefits are all for me.

By wrapping my code in a unit test "safety net" while I'm writing it I can be confident that I will spot potential problems quickly and clearly during development. When a client requests a fix or new feature, I use the unit tests to tell me when the work is done and I can stop coding. When something blows up during integration, I already know what works in my own code, and can quickly localise the problem without searching the whole codebase or considering lots of different failure scenarios.

My clients still do their testing their way. They still find problems which I haven't been able to test. But I feel a lot less stressed, and can turn round fault reports much more quickly and professionally.

From the comments to the one of my previous posts and posts it seems that people just love to judge someone else's design without seeing it. Now, when everything is working and I have time after a day job, I can clarify some points. I feel quite

Read more...
TrackBack to http://radio.javaranch.com/frank/addTrackBack.action?entry=1079341255000