Saturday, March 20, 2010

More TDD

I'm curious if anyone reading this has any experience with writing tests in Eclipse. I've been using Junit, and like it mostly. I find it helpful that I can create a new testing class and specify which already-existing class is to be tested; (and that it automatically populates the test class with all the public methods.) I try to make sure I have all my public methods under test, but I know that sometimes I create a public method and then forget to add it to the testing class. Is there a way to, say, update a testing class so that it will re-populate, adding any uncovered public methods? I suppose I could look into some sort of test coverage plugin.

My current focus is re-getting the display portion of my game up and running. I think I'm pretty close, though when it's there, I won't really have anything to show for it, other than a testing suite with all green checks. (Though, I should be able to create a window and display some dummy information)

Some things that are on my short list to implement: dynamic resizing of the window, zooming in and out using the scroll wheel, etc.

3 comments:

tormodh said...

For new functionality I usually try to write the test first. I've found that the moment I write code first, test later - is the moment I stop writing tests.

Writing the test first means I reference classes and methods that doesn't exist, but a Ctrl+1 lets me create it. TDD are all about writing a test that fails, then writing the code that makes it turn green.

This is really tough to do, or so I find, for personal projects - and especially so for GUI stuff. You are on the right track there; test the public methods; then write display code that does the same thing as the tests.

For a nice history/presentation of TDD: http://www.infoq.com/presentations/tdd-ten-years-later

And to answer your question, have a look at EclEmma: http://www.eclemma.org/

abagoforanges said...

Well, I have been almost exclusively writing my tests first, and I'm also using interfaces for all of my classes. I think my problem is that I'm only mocking out one of my 11 classes so far. So, the issue is that I'll write a test for one class and then have to add functionality in another class (occasionally) to get the first test to pass (and I don't always remember to write a test for the other class.) I'm (For the most part) using dependency injection, so it's not AS bad as it sounds, (as far as classes being dependent on one another)

I occasionally skim through my interfaces and make sure I'm testing all the methods; I just wish there was a 'recheck for untested public methods' or something. Though, after a few more hours of coding last night, I think I really want a test coverage plugin. I'm not (I don't think) going to be one of those people that tests private methods, though at this point almost all of my methods are public as defined in the interfaces.

tormodh said...

Well, yes - then I read you :)

Would like to hear what coverage plugin you end up with, EclEmma or other.

I'm usually testing behaviour only; I write the first test, make it work, and neglect testing the public methods on other objects. When I reuse, the new behaviour tests either pass or show a failure. In case of a failure, I write a test proving the bug (or missing functionality) taking it from there.

I don't get a one-to-one coverage of tests/public methods this way, but I get a proof of it working for the cases it needs.

Then again, my current work project is infinitely less complex than a game. :)