Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Over last one year or so, I have driven my team towards the release-early-release-often mode of development (AKA: Rapid Application Development, not Agile). For more information about the manner in which we close the build, see my answer here: A simple ways to improve the release quality in RAD environment

When we adopted RAD, people were quite independent and they were doing unit testing first; the integrated tests happened much later in the process. It was a natural process for them without much formal enforcement. Now the situation is quite different:

  1. The entire platform is well integrated with established builds/releases working client-side without any hot spots.

  2. New functionality requirements keep coming and we incrementally build them as we go.

  3. The overall dynamics of the system are very important because while independent development groups might be following processes right, major failures have arisen due to complicated, non-obvious circumstances.

  4. Many parts of the system involve new algorithms and research inputs so the challenges (and hence mechanism for testing) are not quite always foreseen correctly, like feature testing in well-defined software.

Recently, I was trying to get better overall picture to see if we need process improvement. When I sat down with my team, many of them balked: "We don't do unit testing anymore!" while others thought we shouldn't start now because it will never be effective.

Are unit tests useful in a relatively mature system? Should we at least need to weigh test scope depending on the maturity of units? Will unit testing slow down the pace of development? Is there a need to evaluate unit testing in a different way?

What are the best practices of testing for a mature platform in a release-early-release-often environment?

share|improve this question
    
I think the idea is to release semi-working code early and often, but the "semi-working" part is implicit. Unit tests help with that. But unit tests may not be sufficient. You might also want a side of integration tests. –  ccoakley Jan 13 '12 at 18:53

3 Answers 3

Unit tests are not primarily for finding bugs in the first place - they are for assuring that the next release of your system is as stable as the previous release. The shorter your release cycle is, the more important does it get that you can run this tests automatically instead of doing them manually.

Of course, if you have a system with some independent parts, and you were working between two releases only at a small portion of the system, you probably can omit some unit tests which are for other parts of the system. But you should definitely use (and extend) the unit tests for the parts where you are working at.

Another thing is that when a system grows, there will be more and more need for additional integration tests - but that does not mean you will need fewer unit tests.

The real question behind yours may be perhaps a different one. Has it become harder to write unit tests since your system has gotten bigger and bigger? Are your "unit" tests are really units tests, or do they not test things in isolation any more? This may be because they rely on lower-level parts of the system which have stabilized over the time.

These things happen because developers tend to re-use existing libraries and code by directly referencing them. It often has the effect that writing unit tests get harder, because they often have to provide a more complex environment and more test data. If that is your problem, then you should learn about at the key concepts Dependency Injection and Interface Segregation Principle, which may help you to make the code more unit-testable.

share|improve this answer
    
"It often has the effect that writing unit tests get harder, because they often have to provide a more complex environment and more test data." <- A unit test should be just as easy for a simple system as a complex one. You shouldn't need more than half a dozen setups for each class. Otherwise, it just means your class has grown too big. Also, unit test shouldn't be tied to any environment. (But you prob know those already, just saying...) –  Sleeper Smith Apr 11 '13 at 0:12
    
@SleeperSmith: yes, and to make it possible to write such simple unit tests, it may be a good idea to apply DI and ISP - that's exactly what I wrote above. Sorry if I was not clear enough on that. –  Doc Brown Apr 11 '13 at 5:45

You should consider looking into test driven development, where the tests are designed first and describe how the new code will work when written. You then make the tests pass.

In my experience this tend to make leaner and better thought out code, especially for libraries, and it is a runnable part of the specification (meaning that it will always be correct documentation).

That said, existing tests are used to ensure that the code still works as expected. It can catch code breakage, and allow you to ensure that third party code still works as expected when upgrading.

share|improve this answer

As suggested by Doc Brown and Thorbjørn Ravn Andersen, a Release early release often environment can benefit even more from good unit testing and test driven development than one with long release cycles.

If you have a good Continuous integration system in place and tests which represent the functionality well, you have a good idea at any point in time what is working (because the tests for that functionality are passing) and what hasn't yet been implemented (because there are no tests for that functionality).

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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