How many developers here write test before coding

I have been reading on JUnit and Eclipse. And also working on a little projects to get my hands dirty...and basically try to understand all the quirks with J2EE.

I have not used XP programming methodology before. I hear people talking about it but not actually witness people using them.

I was wondering how faithfully do developers follow the XP requirement of writing test cases first before coding.

My experiend in using JUnit with Eclipse has been not ver favourable. Perhaps I need more practice. I find myself getting stuck in getting the test setup - not because I do not know what to code but it is a pain to use JUnit.

This, of course, can be due to my inexperience. Can any posters share their thoughts on using JUnit/Eclipse or the "test first code later" methodology?

Ram Dass
Friday, October 3, 2003

It is hard to make the transition, but once you do you will be amazed at how much more malleable and well-factored the code turns out.

A great resource that explains in much more detail how to get started is "Test-Driven Development" by Beck.

Scot
Friday, October 3, 2003

Not that I explained it in any detail :-)

Scot
Friday, October 3, 2003

I write TDD when I can, because the code is generally:

* finished more quickly
* higher quality
* easier to regression test

However, not all development is "green field" (ie, new code) and it may be difficult to use TDD when you are working with legacy code. Typically this is because of political pressure to "just get the changes done quickly and not break too many things".

This fear has some basis in reality: while it may be the best approach long-term to refactor the code and establish a test suite, in the short term many things are likely to break en route from here to there; or, if you are very very careful to not break anything, development may be much slower than management cares for.

A second place where TDD is difficult are frameworks, application containers,  and heavy use of outboard systems (especially databases). 

Many frameworks are simply not designed with testing in mind.

Application servers can make TDD tedious and impractical: either you have to find a special testing framework, or you have to do an awkward 3 step:

1 code
2 cycle the app server
3 run the test

repeat

It can be difficult to use TDD with databases for many of the same reasons. Often you need a live database connection to run the test, and you, the developer, may not have enough control of the DB to set it up for the test appropriately.

You can, however, change things around to simulate the data from the DB, and test your business logic with that. While that's all well and good and recommended, often using the real DB bites you anyway.

Good luck!

Portabella
Friday, October 3, 2003

I write code, test, and documentation all at the
same time. The intent comes first and unites
all three.

somebody
Friday, October 3, 2003

Portabella - thanks for your post. If you have time, you must try writing a manual on TDD. It was very nice to read a succint and insightful post as yours.

Ram Dass
Friday, October 3, 2003

For new code I generally write some sort of test driver along with the deliverable code.  I have been doing this since before anyone thought of XP.  I am not sure how one would develop code without testing.

mackinac
Friday, October 3, 2003

I don't write it before hand (still haven't caught on to XP hehe), but it comes soon after any partial functionality is completed. Usually I try to prototype and document requirements beforehand. Sometimes I have to throw away crap because I didn't architect or code up to the standard I try to maintain. The only exception is when things just don't go your way--like exceptional time and money constrains. Good always do better :-)

Li-fan Chen
Friday, October 3, 2003

All developers should write a  test before coding. If you write a test plan before you code, you may find defects in the requirements or design before you waste your time with a single line of code.  If you know how you plan to test your program, you will understand better how to write it.

Jen
Friday, October 3, 2003

I write tests first, and JUnit is a pain to set-up :)

I ended up realising one day that, hell, I'm writing little scripts all over the friggin place to test. Normally my tests go something like (fictional e.g. only, for the pedantics ;), insert [a,b,c,d,n] into the DB, and I'd give it a squiz to see whether it acts as calculated. And then I'd stick this test in some directory 738 million levels down, just to have incredible difficulty to find it later on.

Well, the logical course was followed, and those tests are now in some unit testing framework (notable NUnit and JUnit). All guys here have adopted it, and we are now a little more strict about writing the text first before the actual method implementation. This works, because the test acts a very detailed spec of what the functionality should be, and the method as an implementation of that spec.

Cannot remember who said this, but the source code is the most detailed description of the required functionality. In the spirit of this tests become a slightly higher level description of what is required. Tests force you to THINK before you touch that method.

It is also actually shocking how useful the unit tests become. It is a matter of practice to make them useful, but as a general rule any unit test consists (at least) of:
- a test using common parameters / set-up (everyday situation)
- a test using rare parameters ("sorry miss, but my dog ate grandma, and she bled over the sofa and as you know I store my homework underneath it's cushions so I can't hand it in today" - type input).
Conceivable, but rare situations (e.g. negative numbers for a process that generally gets positive ones, empty strings for you know when, strings consisting of only whitespace (sMyString.Trim() != 0 versus sMyString.length != 0) errors and so forth in here).
- a test that uses downright wrong parameters and expects an exception. Check exception type and error message.

A set of tests like this simplifies any changes enormously - if your boss waltzes in and demands that a donkey polisher must be added, the test helps with ensuring that the polisher didn't subtly break any other strange thing.

As to XP practices, we don’t strictly hold by everything XP specifies. But certain things happen naturally (like pair programming) and this is encouraged. Pair programming does seem to increase quality, but we have not yet used any measurable test to determine whether this is true, so it might just be a subjective view because I like the ideas in XP :)

Gerrie Swart
Saturday, October 4, 2003

Ugh, dammit the
"sMyString.Trim() != 0 versus sMyString.length != 0"-line
should read
"sMyString.Trim().length != 0 versus sMyString.length != 0"

also: is not meant as language specific :)

It is saturday morning, after a long friday night, so sorry about any typos I don't notice right now...
--kill the bright lights-- ;)

Gerrie Swart
Saturday, October 4, 2003

I do but I'll caveat it by saying I write a description of the tests before I write the code trying to see if I can cover all the cases the code may fail.

*write psuedo code
*write psuedo testcode
*write actual code
*use custome code parser to generate test stubs on
  class/methods
*fillout stubs fleshing out psuedo testcode.

I've seen it written on XP and I practice that  you should write a bit of code then write the test code but I  found thinking about testing before hand could make you aware of traps.

depending on the code defensive code + testcode certainly improves productivity.  Now to nail the architecture so I dont make some fundamental stuffups :)

peter renshaw
Sunday, October 5, 2003

Can anyone recommend any good books or articles that discuss unit testing techniques?

Thanks,
Dave

Dave
Monday, October 6, 2003

Oops.  Nevermind.  I posted this question in another thread. I thought my browser didn't post my response correctly...

Dave
Monday, October 6, 2003

A question from a humble code-monkey which is not
using the state of the art software engineering methodologie ;-)

Do you guys also write test before designing ?
To test that your design is robus & solid ?

Or you just write test plans for the code that you're going to produce ?

Fairight
Tuesday, October 7, 2003

One of the XP philosophies is "do the simplest thing that can work". I don't buy into that for 100% of the time, but most of the time it's a good guide. We do as little design as possible. Definitely, if things are not interacting, then there's no point in having a group design them; the person who's implementing them should be free to implement as they see fit.

We generally have a decent high level feel for the project and design ad-hoc as needed. And we definitely never design anything before it's being implemented.

Brad Wilson (dotnetguy.techieswithcats.com)
Tuesday, October 7, 2003

I and my partner write tests before we write any code.

We do not test the design, as there is no up-front design.

The Pedant, Brent P. Newhall
Tuesday, October 7, 2003

  Recent Topics

  Fog Creek Home