From what I've read of it it seens a really good idea, but in practice the stuff I do at home is in such a state of flux that I feel I'm writing tests and not code all the time. It's almost like you need a certain level of stability to build upon before you get the benifit from unit tests.

I still feel it should be a good idea though. A good argument for using JUnit is in Martin Fowlers Refactoring book (which is well worth reading).

What is the general concencus here for JUnit? (both for home projects and professional)

I have also wanted to use JUnit for my projects... but I find it VERY difficult.

writing tests for trivial methods is easy. All examples I have seen are trivial. How do you test REAL CODE? I asked this on the JUnit mailing list.."how to get started" they said just dive in and go for it.... I have trouble with that. It turns out that anything I want to do needs tests that are at least as complex or more complex than the code they are testing and thus my chance for bugs in the tests is huge.. the debugging effort at least initially is more than doubled... there should be some payoff for maintenance changes.. but if changes require changes in the tests then I'm back to doing a lot more work with more chances for errors.

The concept seems sound.. but I just can't figure out how to apply it without my development slowing to a crawl.

If anyone has a solution to that problem I want to hear it.. because I want the unit tests in place so I can be more confident of my refactorings and such.

First - it is normal that good test routine needs more work/code than code it test. It is also normal that you will make bugs while creating unit test. But, if you hit some error, you pay more attention to it and then decide which piece of puzzle is wrong - implementation, your unit test, or maybe documentation you misunderstood.

One of the tricks I use to write good unit tests is to start with basics and then introduce deliberate mistakes (as small as possible) into class code. If they go undetected, add it to your unit test. This works good for reusable middleware classes, I have not used it for classes at end of food chain - I'm generally more toward using unit tests for base modules then for top ones.

One of basic rules is to have somebody else to write unit test for your code - this way you will also test documentation/javadocs and avoid falling into misunderstaning some process twice in same way.

Writing unit tests is painful, slows down development and is very irritiating if your class change a lot. This is another reason to stick to base classes - their functionality tend to be more fixed over time. But testing small modules is only way to make reasonably working system - debugging top level classes while you cannot trust your base is bad for sanity... For system large enough, bugs in low level code is going to cause more headache then testing it through unit tests.

P.S. In my company, writing unit tests is also used for newcomers so they will know system better - at the same time, they are more likely to find some incosistency/bugs which everybody else is used to avoid subconciously (sp?). And most older programmers really, really hate this job

I have also wanted to use JUnit for my projects... but I find it VERY difficult.

writing tests for trivial methods is easy. All examples i have seen are trivial. How do you test REAL CODE? I asked this on the JUnit mailing list.."how to get started" they said just dive in a go for it.... I have trouble with that. It turns out that anything I want ot do needs tests that are at least as complex or more complex than the code they are testing and thus my chance for bugs in the tests is huge..

I hit the same problem, especially when theres just one person working on a project it seems like a huge overhead.

There wouldn't happen to be a java equivilent to Rational Robot would there? Or is this perhaps built in to JUnit and i havn't seen it?

This works good for reusable middleware classes, I have not used it for classes at end of food chain - I'm generally more toward using unit tests for base modules then for top ones.

I agree with this. I mean, I can see how I could write unit tests for an API or something very discrete like that. But the application itself is more of the glue that times all those discrete things together... it is more blob-like, tying together unrelated bits in complex ways.

Quote

Writing unit tests is painful, slows down development and is very irritiating if your class change a lot. This is another reason to stick to base classes - their functionality tend to be more fixed over time.

No argument with the "painful & slow" point... but your point about testing bases classes because they don't change often seems counter to the point of unit testing in the first place. If I don't change the base class often, I can spend the time to be really careful when I do, plus I have all those derived classes in my app - perhaps one of which is likely to break in a noticeable way if the base class has a bug.Isn't it the code that changes that needs to be constantly tested?

I think it's difficult to unit test in such a way that it's beneficial. Unit testing done wrong can just lead to many headaches and worst, false positives.

I worked on a project recently where the unit tests violated the public interface to do their job. This caused so many problems it was ridiculous, totally negating any value the tests had. Any change to private implementation meant also changing the tests to correspond. Since the tests used private implementation we really should have "tested the tests", but of course didn't. So there were a lot of situations where the unit tests would all report things were ok but there'd be glaringly obvious bugs in the program, it was just a big mess (and not my idea )

One thing that unit testing is great for is when new people jump onto a project. Changes they make that cause tests to fail can allow them to learn the code a lot faster.

Warning: this topic has not been posted in for at least 120 days.Unless you're sure you want to reply, please consider starting a new topic.

haha....

My question is totally different from the topic above.. my question is if JUnit alone is so difficult to use then why other developers care to integrate JUnit into other applications? Isn't that stupid?

JUnit and creating test suites with it is very simple. The problem is to create and maintain _meaningful_ tests.

Here at work, we really benefit from having unit tests, since it's the only way to say, if our system works the same way as intended after changing something. You will be surrised what kind of sideeffects can occur in a software that is little more than trivial.

On the other hand we don't use JUnit to test whole applications. We use it to test the base logic and data models of our applications. To test the applications itself we use plain old test protocols and test the functionality by hand.

Since my earlier reply I've actually had a chance to do proper test driven development (TDD) with unit tests and it went very well (not with JUnit though, a custom C++ unit testing framework).

I think it's not particularly difficult, but it does require quite a mental leap from what everyone probably does without thinking now - just trying to carry on before and bolt some unit tests on later is definately not the way to go and is always going to be painful and unproductive. Instead you've really got to shift to doing proper TDD ("Test-driven development by example" by uber programmer Kent Beck is a very good place to start).

IMHO theres two main shifts you've got to make - writing tests first, and *really* concentrating on dependancies.

Writing tests first means that you're focusing on what the external interface should look like. You're not thinking about the internals (much), but how people will actually use your software. This means you get tigher, smaller interfaces which are more useful.

Thinking about dependancies means paying attention to what dependancies you need for each test, and whether the dependancies between classes and modules is sensible. If your tests are big and hairy and complicated that probably means your classes are too dependant on each other. With well-factored code most tests can be ~15 lines long. The book "Working effectively with legacy code" is basically about retro-fitting unit tests onto an existing code base, and most of the book is dedicated to dependancy breaking techniques (which are somewhat different from regular dependancy management work).

For the first couple of weeks I found I was somewhat less productive, but after that mindset shift then it was much quicker. You know instantly when you make a change that breaks existing code. Other people are less likely to break your code (and when they do you can beat them around the head with your unit tests). My defect rate dropped dramatically and stayed low, even as the code base started to get bigger and bigger. You're also much more confident with refactoring and more likely to make those big changes you know you really should. The tests also make great documentation - "how do I foobar a gimlet?" "look at foobarAGimletTest()".

I'm now thinking of adding more tests to my own java games. IMHO the higher level code can stay without tests (because it's higher level, and because theres only me working on it) but lower level stuff should definately be worth it.

hmmm an old thread (is it me or have threads circa 2003 being popping up alot today?) but interesting....

I've not had chance to use full on TDD yet it's one of those things that I want to exprience in practice. At work JUnit tests are required but treated very secondry. It's not so much TDD more units tests are good do unit tests.

OT your post was interesting as I think it is that big mind set jump that I need. I have tried doing a bit at home with my simple projects. But I found that I spent all my time writing tests and not actually getting much code written.

The thing is I can't think of a good reason not to do TDD, just a bad one, the perceived "but that takes me twice as long and I don't have much time as it is". How do you get over this feeling?

Without putting too fine a point on it, I think OT hit the nail on the head - the ease of writing unit tests is proportional to the quality of your code (measured by OOP standards) - and this is why you see huge variance in people's experiences *and* why long term experts say "just dive in" (because for them, and all code they write, and code they expect you to write / have written, it really is that easy).

And IMHO that is why they're fundamentlly so valuable *** - they coerce your code into being better.

***: there are several other areas where they happen to be invaluable for (so far it seems to me) unrelated reasons. For instance, automated and stress testing of massive complex systems, pre- and post-refactoring testing, and others. But I've not really thought about that any more than "huh, they work fantastically well here and I can't see an obvious reason why other than that they are good tests and that I have approximately as many tests as I have public methods" (which, for instance, is why they're invaluable in AT and ST: they exercise almost the entire code base very quickly).

OT your post was interesting as I think it is that big mind set jump that I need. I have tried doing a bit at home with my simple projects. But I found that I spent all my time writing tests and not actually getting much code written.

The thing is I can't think of a good reason not to do TDD, just a bad one, the perceived "but that takes me twice as long and I don't have much time as it is". How do you get over this feeling?

Largely it was a combination of external situations, without going into the specifics I and a few others were thrust into a different project to get some results fast. There were a whole bunch of big unknowns (new codebase, new hardware, new techniques) and I felt I really needed a safety net. Since unit tests were being used (in principle at least) I jumped on the oppertunity to do things a different way.

It was much slower for the first couple of weeks, and had I been doing it for just hobby stuff I'd probably have given up. But after that initial hump it's a much nicer way of doing things.

Haha.. everyone is talking big talk.... do not understand... i am such a noobie...

* yeah, we got someone else intimidated by buzz-words *

It's actually super-simple ... but as with many tools out there, it sounds complicated as hell. Basically all you do is test some code. I usually do JUnit tests for client-server functionality. Helps to find bugs before adding it to my my games. You do not actually need JUnit for testing, you could just write some code into the main(...) method to test functionality. E.g.

in testAll() you can use some methods such as "assert" and "fail" to simplify testing. JUnit tests integrate nicely into your build process.

I usually write the tests first (i.e. code in "testAll") and then implement the actual classes that I am planning to implement. It gives you an idea what you are actually planning to do before you write the code you want to write!

You do not actually need JUnit for testing, you could just write some code into the main(...) method to test functionality.

Yes but use of JUnit is highly recommended. It's the integration into build systems and IDEs and overall standardization that JUnit gives you that makes it so useful.

I've used unit testing (NUnit in a .NET environment) to great success at my job. The amount of debugging required for the project was reduced significantly. The flexibility of the code was greatly increased as the impact of changes was easily captured in the unit test results. And other developers used the test code itself as an introduction to how the real code worked. There's no doubt that TDD is good stuff.

There's also TestNG (testng.org) . It's not much different from JUnit but it has a few more nifty features, like the @DataProvider annotation which declares a source for parameters to your test methods:

JUst asking... when we are packaging up all our class files, is it recommended to place our Junit files in it as well? Cause I am not sure if the next person who takes over will generate his/her own files.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org