0

At some point you have to decide which parts of your programm you want to cover with unit-tests.

If you're developing test-first then you're off the hook as you already have your test cases. Congratulations. If you're not so lucky (that's the case in our project) you have to decide for which parts of your programm you are going to write unit-tests.

Is there a good and methodic approach to decide what to cover with unitt-tests? Ecspecially one that is more specific than asking yourself what should I test here??

Kaadzia
  • 1,393
  • 1
  • 14
  • 34
  • You got it all turned upside down. Unit tests are to test the smallest bits worth testing, individually. And testing for all execution paths/different behaviors/important corner cases. – ppeterka Sep 19 '13 at 11:30
  • I didn't mean one unit test for all that. Definitely a separate unittest for every bit worth testing. – Kaadzia Sep 19 '13 at 11:32
  • I understood you don't want one test, but still: what your question sounded to me is more like [integration testing](http://en.wikipedia.org/wiki/Integration_testing) than [unit testing](http://en.wikipedia.org/wiki/Unit_testing)... Integration testing is when you test interoperability of larger than "smallest testable unit" parts of the code. – ppeterka Sep 19 '13 at 11:34
  • 1
    No, that's not what I meant. I want to test the small bits that make up the application. e.g. if a public method inside of one of the classes works properly. Any ideas on how to rephrase the question to make that clear? – Kaadzia Sep 19 '13 at 11:38
  • I think that this is a subject of Quality Assurance, sqa.stackexchange.com – Val Sep 19 '13 at 12:48
  • how can we decide what you need to test? ideally: test everything. – Nanne Nov 05 '13 at 16:20
  • @Nanne: Now I just need the definition of `everything` ;-) Every line of executable code? All non-generated code (e.g. excluding getters and setters)? Every functional line (e.g. excluding error handling)? Every public method? ...? – Kaadzia Nov 05 '13 at 16:29

1 Answers1

2

IMHO:

  1. Everything in the original specification.
  2. Everything that is relied upon to work forever.
  3. Everything that you found broken and had to fix.

Not terribly helpful I am sure - but realistic.

Unit tests should cover as much as you have time for and then cover everything you did not have time to test the last time you worked on them.

What approach can be used to find chunks of work worth testing?

There are many:

  • Whenever you find a bug, fix it and create a test that will ensure it never returns.
OldCurmudgeon
  • 64,482
  • 16
  • 119
  • 213