Anyone use jUnit?

[20thCenturyBoy]

I'm just reading up about jUnit and it looks pretty useful, do any of you guys use it? Presumably it would be just as useful for J2SE game devs as for J2EE devs. If you do use it do you find it speeds up development time?

20thCB

[D.t.O]

jUnit is pretty good at doing what it is supposed to do.


In the beginning, it slows dev time, but in the end, IMO, you save time because you can re-run the same test cases (as opposed to ad-hoc testing).

Wow. That really sounded like some lame cliche. Sorry.

[kevglass]

Since I rarely get games past the concept stage JUnit hasn't given me any benefit so I've stopped attempting to use it since it uses up my inital dev time.

However, the concept seems pretty sound.

Kev

Games published by our own members! Check 'em out!

[vrm]

I use it for validate some aglorithm, I find it pretty usefull. I try to write the test code first (not all the time ) )  for validate the conception, in place of writing an UML scenario diagram

[Herkules]

helps maintaining base libs. I use it.

[morbo]

Using automated tests takes some getting used to, but once you start you'll never go back. And JUnit is the authority in this area, so yah it's good.

Test suites do take some maintenance: normally if you change the behaviour of a method/class, you only have to update the client code, now you also have to update the tests. But this is trivial compared to the benefits.

With a comprehensive test suite, you're free to make major implementation modifications without fear, and without the need to perform extensive manual testing afterwards (as long as your tests accurately represent how you're using the code in the project itself). This is even more benificial in team development, were developer B can modify developer A's code without fear of breaking the behaviour.

I also use unit tests to help in design: by writing the test case up front, I get a better idea of how the class will probably be used, and what clients may end up doing to try and break it.

There's nothing like the warm fuzzy of changing a thousand lines of code and then having 0 errors in your suite of 500 tests.

[swpalmer]

I have wanted to use JUnit for over a year now.. however I must say I can't figure out how to get started...   Right off the bat the workload is doubled in terms of designing and maintaining good reasonable tests.  In fact in many cases it seems that the tests are more work than coding the test the application.

I would love to have the unit tests available.. but I don't know how to make them less "expensive".   My time debugging is MUCH less than the time it would take to design and build (bug-free) tests.

If anyone has the secret please let me know.  So far all I've been told is that you just have to dive in and start doing unit tests.. well that's fine, but I haven't got the luxury of tripling my development time.

[blahblahblahh]

SWP: IME, you need a good harness for running the tests. Unfortunately, JUnit is almost non-existent - it does practically nothing - and I've been watching it for ages hoping it would (eventually) grow and gain a complete set of harnesses...

If you look around the junit site, you can find lots of 3rd party harnesses and if you're lucky may find ones that suite you. But there aren't that many .

For instance, we've coded unit-testing support directly into the core gameserver for the GrexEngine; this means that writing new unit tests is fairly simple: you can assume that the whole gameserver is already up-and-running and that various config and init stuff has already happened. This is more than just an "init-stage" for the unit-tests (can't remember what jargon name junit uses for it ), because the tests themselves are only invoked from inside a pre-configured pre-started game-server. If you invoked the tests from outside the game-server, and had "starting the server" as part of the test, it would add minutes to the exec time of every test, and would be very error prone and hard to maintain.

The other part of unit-testing where you can save a lot of time is by learning to be cunning about the tests you run. XP people often say "test everything in the contract, then add a test for every bug you ever find", which is good, but...there's definitely a mindsight that lets you write new unit tests from scratch about 5 times as efficiently as if you do so naively. I'm pretty sure there are articles spread out on the web which offer advice on getting into this mindsight, although I've not yet seen a "thinking in unit-tests" (come on, Bruce!) which would be very helpful to many people I suspect.

I find that the most effective *initial* unit tests are ones written by ignoring the spec and all the implementation. Instead, start from the use-cases (if you don't know what use-cases are, do a google; they're a simple concept used widely, e.g. in UML design). Just write unit-tests that mirror the use-cases; this generally is a lot less than testing the contract of the method/API and yet exercises 99% of the downtime/damage that bugs will cause to user-code: people code to contracts less closely than they code to use-cases .

[Herkules]

There IMHO is one big objective against test-driven development, that is if you have hundreds of tests and then need to change code interfaces or use-cases significantly (or sometimes only a little) .... you have to re-evaluate all tests against the new specs. And this can be a real pain-in-the-ass.
Esp. then there is no good mean against bugs/misunderstandings in the tests themselves and many might get pretty meaningless or even wrong.

So what about tests for the tests (having a recursive problem domain)?

Concerning tests in complex environments: yes, difficult with JUnit. setup() and teardown() are no suitable places to start and shutdown servers. One way around that is to work with mock server objects to test clients.  Sometimes it is possible to create them.