19

Should I write the unit test cases for a frequently changing product?

For example: I start the project with Phase 1 (say it's 6 months long) and I know there will be a phase 2 (3-4 months or more) which will change major features of Phase 1. Should anyone need to spend the time/cost to write the test cases in Phase 1?

So is it good practice to write the test cases when the features may change in the 2nd phase? Instead of this automated testing one can opt for manual testing.

Improve this question
1
  • 16
    Should anyone need to spend the time/cost to write the code in Phase 1, if lots of it's going to get thrown away? Presumably you're doing that because you don't know which bits; you're going to learn and iterate. But you're going to want to be confident that the bits you don't remove still work through that process, and automated tests (unit or otherwise) give you a substantially shorter and more repeatable feedback loop.
    – jonrsharpe
    Aug 6, 2020 at 6:40

5 Answers 5

Reset to default
34

Yes that is the ideal situation for Unit tests

To look at a different situation - if you are writing software that will not be changed in the future then perhaps you could consider skipping the tests. I have yet to work with such software of course :) Also TDD and BDD proponents would argue that even in those cases you should still use those techniques. They treat testing as an essential and critical part of the design process rather than than the more traditional 'verification checking' approach used for testing.

Units tests area should be proactive, built-in way to make sure the code works and can be changed in the future without breaking it.

So if you truly practice TDD and write the tests before the application code that makes them pass in order to make the tests drive the implementation then skipping tests is not even something that will happen. If, however, tests are written to meet the 'minimum coverage % level' and are written after the app code then their value is reduced and the quality will suffer greatly.

You may think that you will have time to write unit tests once the product settles down. This is a very common fallacy and will usually meet reality when you ask the product manager for a few weeks to write tests and not be implementing features... Such a statement will usually not work well and in my experience, that practice never happens.
It's worth repeating that - IT AIN'T GONNA HAPPEN

If features are changing frequently, that is precisely the sort of situation where unit tests are a programmers best friend, making sure they don't break stuff despite the high churn of change.

Think of tests as a programmers most valuable tool and one that should not be avoided.

I consider manual testing very valuable in all cases but I do consider 'unit' tests to be automated by definition. This means you can have extensive manual testing without Unit tests existing, i.e. development before 2000 :)

One final note on software that never changes - one example is software that goes on-board space vehicles - wanna guess if they test that? (see Mars Climate Orbiter for an example of what was not tested appropriately. Oops.). So we have learned to test that sort of never changed again software quite a lot.

Separate testing from development and you separate quality from the act of creation

Improve this answer
3
  • 3
    I don't really agree that tests can be skipped on software that doesn't change, especially if you consider a TDD or BDD approach.
    – bracco23
    Aug 6, 2020 at 14:47
  • @bracco23 Thanks. I agree with you and have modified the post accordingly :)
    – Michael Durrant
    Aug 6, 2020 at 19:59
  • 1
    It seems fair to me - if the software never changes, it will surely be faster to test once by hand, than to write enough unit tests. Of course as a developer you wouldn't be thinking about it if there really was no change, and if it's "just this once change" I'd be highly skeptical. But if it genuinly won't change then yes, unit tests aren't efficient. Without changes what does the last D in TDD/BDD even mean?
    – Mark
    Aug 7, 2020 at 13:35
16

Yes, the idea of writing the right form of unit-tests is that it keeps the cost of change low. If you make a lot of changes they are here to help you go faster.

The biggest mistake most people make is too test implementation instead of behavior, which increases the cost of change, because you build change detectors. The tests should help you refactor the architecture to fit the new change with ease.

Reads:

Improve this answer
5
  • Unit tests will always be testing implementation at some level because they are bound to concrete classes and methods. That's what makes them inferior to higher level testing.
    – Davor
    Aug 6, 2020 at 17:04
  • 1
    @Davor a unit is not necessarily a class, a unit test can well test an interface and thus not be implementation specific so, no not always. Even if you go for methods, that can still be a relatively abstract test, i.e. you should be able to change all the inner workings of a class and still keep the public methods intact. Sure you might need to adjust some mocking. But you might also be so deep down that your unit test is not affected by everything around it changing as long as its unit's contract stays intact. Unit tests aren't inferior, they simply have different properties.
    – Frank Hopkins
    Aug 7, 2020 at 0:25
  • @FrankHopkins - no, you can't test an interface. You can test a class implementing an interface, and the interface is also an implementation in itself. And so is the existence of a method. Unit tests are useful only while the public interface of a class never changes, which is almost never.
    – Davor
    Aug 7, 2020 at 11:43
  • @Davor you don't test the interface but you test against the API the interface defines and that is less likely to change than the internal logic of a an implementing class. With your argument everything is an implementation because everything on every level is prone to change at some point. And no, unit tests are not only useful when stuff doesn't change. They are particularly useful when public methods and especially interface methods change (implementation details or the interface specification), because they then reflect the adjusted contract and give you certainty it is upheld.
    – Frank Hopkins
    Aug 7, 2020 at 11:57
  • @Davor but alas, since this isn't about improving the answer nor about helping understand any more, I'm out of this discussion.
    – Frank Hopkins
    Aug 7, 2020 at 11:58
7

Yes. Because those bits that do not change still need testing. The rest that does change, well, that's just a part of the process, you simply need to change things once in a while. Writing tests makes you think about the whole problem, which is alone a good practice to do. Without tests, problems might remain in the product until later, which might be then costly to fix.

Instead of this automated testing one can opt for manual testing.

These are not opposites, it's not one or the other. Each of these is suitable for different problems and risks.

Improve this answer
2

There is exactly one point where writing unit tests would be just a waste of time: if you're already using a dependently-typed proof assistant to mathematically guarantee correctness for all inputs. That is given for an estimated 0.01% of all software development and evidently not in your case.

In all situations when using a normal programming language, unit tests are a good idea and will statistically save more time in debugging than they cost in writing. This holds true even for simple one-off scripts, and as said by the other answers actually much more for projects that will change a lot in the future.

Improve this answer
0

This scenario is faced by every qa person in the projects in every qa company where they get confused with this situation.

Writing unit tests is a subtle approach for phase 1 features because it helps to keep track of the features behavior in phase 2. Moreover, execution of these unit test helps to find the behavior of the feature in phase 1 and phase 2. Apart from this, features that are not going to be changed in phase 2 can be automated to speed up the testing during phase 2.

Improve this answer

Your Answer

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

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