How many actually use unit testing?

[Selkirk]

So of ~4700 lines of PHP, more than 2500 are in the tests directory, over half of the entire project.

If I recall correctly, WACT has a similar ratio (1:1) of tests to actual code.

[sweatje]

If I recall correctly, WACT has a similar ratio (1:1) of tests to actual code.

Here is the count for a recent cvs checkout.

SLOC    Directory       SLOC-by-Language (Sorted)
13712   framework       php=13712
12305   tests           php=12283,sh=22
1935    examples        php=1935
504     benchmarks      php=370,sh=134
92      make            php=92
63      top_dir         sh=63

[R. U. Serious]

I have a question for those that are using unit-tests as test-driven development: Do you decide intuitively on what to write tests for and what not to write tests for? I am asking because one of the advantages that I keep hearing mentioned is that tests are a safety net when doing refactoring ("it will catch mistakes"), but if am not sure how effective that is, if your test cases are only based on intuition.

Don't get me wrong, I am not against unit-testing. But I sometimes feel like people seem to think that unit-testing is all about testing, when imho it is really all about developing. So my second question is: Besides test-driven development, do you have other more formalised tests you write and use?

[lastcraft]

Hi...

Besides test-driven development, do you have other more formalised tests you write and use?

Yes. Unit testing cuts down on the need for these quite dramatically, but they are still there. Every project has different categories, but here are a few I have come across:

1) QA/Acceptance testing. Testing that a feature is implemented and to a sufficient standard. Would include such things as an acceptable number of results from a search field or that things run sufficiently quickly when loaded.
2) Rollout/Deployment/Functional: Testing that everything is wired up correctly on the machine it is about to start being live on. End to end black box tests.
3) Integration tests: Testing more than one unit at a time, but still not the whole system. White box testing of tricky systems.
4) Monitoring: Health checks on servers, uptime checks, etc.

yours, Marcus

[McGruff]

Do you decide intuitively on what to write tests for and what not to write tests for?... not sure how effective that is, if your test cases are only based on intuition.

This is the million dollar question: what exactly do you test in order to prove the class does what it's supposed to do?

The less you put in the test, the easier it is to read. I guess it's a general programming skill to be able to express yourself elegantly, ie to say a lot with little code. On the other hand, sometimes you might deliberately expand on a particular point just to make it clearer.

You don't want to over-constrain the solution since, if you try another implementation, this could cause an otherwise acceptable solution to fail.

Most of the time I'm looking for an inductive proof. In mathematics, you'd sometimes prove a theorem by proving it's valid for 0, for 1, and for any other number. You don't need to test every possible number just the special cases and something representative of all other cases. In a unit test, that might mean testing with an empty array parameter as well as an array with sample values. If it's a class to parse nested tags, you'd maybe test it with a string with no tags, with a single pair of tags, and then with tags with one nesting level. If it works with that, it's probably safe to assume it will work with any nesting depth. You can always add more tests just to be sure - at the risk of making the test less elegant, ie less simple than it could be.

Exactly what you need to do depends on the class itself. There's always going to be a lot of thought going into these decisions. That's one of the good things about the testing discipline since it often forces you to think more carefully about the class's behaviour. You can always add more tests as new issues come to light.