7

I'm building a solo project myself. (Java backend, Java AWT frontend. No lectures about AWT vs swing vs *wt, please :-))

It's fairly straightforward

Primary server - keeps user information Content server - keeps content information Client - the user interface

Client opens up and connects to the primary server. Depending on the content, the connection gets bounced to the proper content server (of course, the primary and content servers do some communication to prepare the authorization of the new client coming in.)

At what point should I be writing tests? I want to balance the testing aspect of it with making progress in development, and I'm not sure what the proper balance of that is. I'm much more concerned about the front end than I am about the back end. I pretty much see the GUI as a simple mechanism for calling back-end functionality with a lot of cool pictures. :-)

Obviously there are paradigms like TDD which would dictate no code is written without a test. But this is just my moonlighting project that I do in my spare time. It's mostly for fun (although I'd love to see a profit off it.)

There's currently between 30-40 classes. There are currently no tests of any kind (unit, functional, integration are what I plan to do eventually.)

How do I know when the right time to stop development and put some tests together is?

Improve this question
3
  • How do you test the code now? How often do you repeat the same tests? You will write more stable code if you have a suite of tests you can run against it.
    – Randall Bohn
    Commented May 3, 2011 at 21:02
  • @Randall there are currently no tests. It appears I left out a very important word (namely "no") from my second to last paragraph.
    – corsiKa ♦
    Commented May 3, 2011 at 23:26
  • 1
    I appreciate that you're already up to your eyeballs in classes but from my experience (and for future reference) using TDD is not only a testing approach but a very effective design / implementation approach too. It helps you implement what you really need rather than what you think you need.
    – LRE
    Commented May 3, 2011 at 23:39

2 Answers 2

Reset to default
2

My recommendation is to start adding tests when you encounter bugs. If you are using some sort of bug tracking software (Trac integrates with SVN pretty well), then you might do what I do, which is to name the tests after the bug report numbers (so for bug 1234, the first test is named something boring like Test_1234 and the second test for the same bug is Test_1234_A). Then, when your ANT tests run, you can quickly see if you have reintroduced previously reported bugs. This is real helpful when you take long breaks from coding (like on a hobby project, or something that gets occasional annual updates) where you don't remember if you've seen some bug before.

Probably the worst thing you can do is to stop coding and do nothing but writing tests, as that will get you sick and burned out (and probably abandon the whole project). If you find yourself doing a certain test over and over again, that is most likely a good candidate for adding an automated test.

Improve this answer
6
  • 1
    In my opinion it is much better to name tests based on what they are testing. If test_1234 fails, you don't have any idea what is wrong with it. But if test_approve_document fails, then you have a pretty good idea of what might be broken.
    – Jason Ward
    Commented May 3, 2011 at 21:16
  • 1
    @Jason, tests for approving documents would indeed be test_approve_document, but bug #1234 might be "can't approve documents with networked drives when local disk space is low and using firefox" (this may sound like a joke, but it isn't too far off from some of the bugs we encountered at my last employer who I'd rather not irritate too much). It needs to be clear that it is an existing, documented bug, and if it breaks, one needs to know immediately that something broke regressing previously fixed bugs.
    – Tangurena
    Commented May 4, 2011 at 0:39
  • I'm actually going with this as the answer. I know it isn't as popular as the "test now! test now!" idea, but it's very practical. I've been doing this approach for the past month now, and it's been working out well. Honestly, between a wife and daughter, work, social obligations, and R&R, I only get about 4 hours a week to work on my solo project - I certainly don't want to spend those 4 hours writing tests. But, I do want robust code. So I've been writing my code and when I run into something particularly tricky, I write the test around it.
    – corsiKa ♦
    Commented Jun 9, 2011 at 17:05
  • I know this isn't the "best practice" for production code, but I'm far from a production state. If this made me any money, I would pretty much be forced to take a step back, throw together my tests, and go forward from there with a TDD approach, at least a TSTITNF approach (Test SomeTime In The Near Future, you can just put a little dash and my name by that, mmhmm) Until then, since it is indeed just a side project, I think this practical, balanced approach is the way to go.
    – corsiKa ♦
    Commented Jun 9, 2011 at 17:07
  • Adding tests after bugs have occured is the same as shutting the stable door after the horse has bolted... You should be adding tests before you write your code, google TDD it's a ball ache at first but the benefits far outweigh the negatives! You will end up with much more stable software and you will waste much less time trying to diagnose hard to find issues later on in the project. TDD results in a slower start, but means you fly along in the middle and at the end whilst others are bogged down trying to work out wtf is going on. TDD = better design!
    – Ardesco
    Commented Feb 21, 2012 at 10:37
13

The right time depends on the development process you are following. Using a simplified interpretation of an agile process would probably work best - pretty much anything that preaches interative development with fast & often builds + test execution after every build will do just fine.

One thing to have in mind is Test-driven development which mandates that tests are written before any code gets created. This way you're developing code to make your tests successful and abide by your spec. As soon as a new feature gets the green light for the project a spec + tests should be created before work is started on anything else.

Of course this is just one approach. The right answer to your question - when to stop developing & create tests - is NOW. No matter what phase the project is in, no matter how little or how much work has been done, NOW is the time to test it.

The only wrong answer here is at the end, when you've put into loads of work and expect everything to be working. It won't. It never does. You, on the other hand, will be reluctant to throw away the seemingly working code due to broken tests at the end.

Hope this puts you in the right direction.

Improve this answer
0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.