-1

Should unit tests be written by the developer who wrote the code or someone else ? And how effective is writing units tests as a method of learning a new system ?

marked as duplicate by Telastyn, Doc Brown, Konrad Morawski, gbjbaanb, durron597 Jul 22 '15 at 15:52

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 4
    The unit tests should be written by the developer who writes the code, before she writes the code. – Carl Manaster Jul 22 '15 at 14:13
  • @CarlManaster it isn't any different with male developers I believe (and yes there are some) – Konrad Morawski Jul 22 '15 at 14:53
  • 1
    @KonradMorawski perhaps we should do something about the gender disparity in our profession and our community. – Carl Manaster Jul 22 '15 at 15:09
  • @KonradMorawski "she" is a generic placeholder, it doesn't imply the programmer is actually female. I've seen it used in many programming books as a way to balance the use of the generic "he" (which also doesn't mean the programmer is actually male). – Andres F. Jul 22 '15 at 15:24
  • @CarlManaster why not, but this, in my opinion, doesn't do anything - it's rainmaking, with all due respect. But whatever soothes your soul ;) I'm not here for arguments – Konrad Morawski Jul 22 '15 at 15:39
3

@CarlManaster has the right idea: It's the responsibility of the developer to:

  1. write a unit test,
  2. verify that it fails,
  3. implement it,
  4. verify that it succeeds,
  5. refactor the feature without failing the test, and finally
  6. refactor the test code

for every feature. The reason for each of these can be summarised as follows:

  1. Writing the test before the code ensures that the problem is sufficiently understood to actually do the right thing. You can still do exploratory programming, but TDD means you then have to throw away the result and start again by writing tests.
  2. If your test doesn't fail before implementing the feature, you typically are either testing the wrong thing or you don't understand the problem well enough.
  3. Implementing the actual feature is kind of the point :)
  4. Verifying that the test now succeeds makes sure that you have a short cycle to fix it.
  5. Refactoring is crucial to make sure the complexity of your application doesn't get out of hand. If you have tests for every feature refactoring them shouldn't break anything.
  6. Test code should be refactored for the same reason as above. This can be tricky since you need to make sure the tests still test the same things as before. One way to avoid breaking them is, for each test that you touch (directly or indirectly), to break it by changing for example a single character in the expected output, and running it to see that it fails for the right reason. Then just undo the change, and the test should still pass and still do the right thing.
  • 4
    This is only true for TDD. What if you aren't using TDD? Or if you have legacy code that doesn't have unit tests (or sufficient coverage)? – Thomas Owens Jul 22 '15 at 14:18
  • @ThomasOwens In my experience, trying to get sufficient test coverage for a large legacy codebase which wasn't designed to be properly testable by unit-tests is an exercise in futility. – Philipp Jul 22 '15 at 14:22
  • New components in legacy codebases can often be written to be testable, and writing tests before or after that has worked in my experience. – Mike Partridge Jul 22 '15 at 15:26
1

Directly testing your own code is good form, and a system that encourages someone other than the developer to test it is a hazard, as the code may not even be testable without heavy modifications.

That said, expanding a project's unit test suite is a great way to get yourself on board with now it works.

TDD style test first coding works very well in a situation where you have a specific feature that has been described in detail that needs to be implemented, but it isn't going to help with more in depth architectural decisions.

0

Writing unit tests is part of the design process, whether you do TDD or not. So of course it's something to be done by the developer.

Integration tests, now these can be written by someone else.

Unit tests, however, are closely related to implementation and they affect the architecture.

Because even if we don't use TDD approach in strict sense, we should still design with testability in mind, so even writing unit tests post factum still has an impact on our code.

It's not only a method of learning, it gives us precious feedback on correctness and maintainability of our code. Furthermore, unit tests are a (quite valuable actually) form of documenting it.

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