I've recently been tasked with testing some COM objects of the desktop app I work on. What this means in practice is writing a large number (>100) unit tests to test different but related methods and objects. While the unit tests themselves are fairly straight forward (usually one or two Assert()-type checks per test), I'm struggling to figure out the best way to write these tests in a coherent, organized manner. What I have found is that copy and Paste coding should be avoided. It creates more problems than it's worth, and it's even worse than copy-and-paste code in production code because test code has to be more frequently updated and modified.

I'm leaning toward trying an OO-approach using but again, the sheer number makes even this approach daunting from an organizational standpoint due to concern with maintenance. It also doesn't help that the tests are currently written in C++, which adds some complexity with memory management issues.

Any thoughts or suggestions?

closed as not constructive by user8, gnat, GlenH7, Ryathal, EL Yusubov Oct 25 '12 at 18:48

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
  • @TomSquires: IMHO that won't help really - if I remember correctly, there is not much in that book how to organize your unit tests. The primary focus is how to change your legacy software to make it more testable, which is not the question here. – Doc Brown Aug 21 '12 at 19:25
  • 1
    So if C++ gives you a headache, why not use a different language? Any COM enabled language will do it, for example C#, which allows you to use the NUnit framework, which has support for things like data-driven tests. Also, the available refactoring tools for C# are much better (at least the ones provided by Microsoft). – Doc Brown Aug 21 '12 at 19:30
  • Wait, what? "Test code has to be more frequently updated and modified"? No. Once those tests are done, they should not be modified unless the specs themselves change. You might add tests, but the ones you have should remain the same. – cHao Aug 21 '12 at 19:48
  • Maybe this could help: xUnit Test Patterns: Refactoring Test Code – Songo Aug 22 '12 at 12:45

Any thoughts or suggestions?

Focus on one test at a time. Be consistent from one test to the next. Reevaluate your approach once you have ~10 tests under your belt.

Realistically, 100 unit tests at ~6-10 lines of code a piece is like a week's worth of work. Annoying, tedious work... but not a lot of it. Put your head down and don't over-think things.

  • +1 for the Q:"how do you eat an elephant?" A:"One bite at a time." type remark. Excellent advice to circle back around and re-evaluate after the first batch. – GlenH7 Aug 21 '12 at 17:15
  • +1, ~100 tests does not really sound as a really large number of tests to me, too. – Doc Brown Aug 21 '12 at 19:32

I'd like to offer the opposite opinion from Anton.

Unit tests are code. The fact that they are not shipped to the customer detracts in no way from their importance to your code base. They are an investment of your programming time that repays itself in the improved speed and accuracy of further modifications of the code base; therefore they merit any good design principle that would apply to your business code.

You give some hints about how duplication in the individual tests could be avoided; I say go for it. The improved understandability of a large test suite more than makes up for the effort of deduplication. Complexity of code, cyclomatic or otherwise, is of course a pressure that you should avoid as far as it's reasonable, but never let fear of abstraction prevent you from writing your tests as professionally as your application logic.

  • 1
    I don't see your answer as contradicting Anton's, except for his last sentence. Keeping them simple (aka low cyclomatic complexity) is good, and all of the other points you make are excellent. – GlenH7 Aug 21 '12 at 17:14
  • I don't mean that you should write bad code. But I tried to emphasis the idea. Tests are the code too. – Anton Sizikov Aug 21 '12 at 17:18

Don't forget that Cyclomatic Complexity of your tests must be the lowest (about 2). That will help you to avoid making bugs in unit-test. Tests must be as easy as you can do. So, don't try to make the best design and use all design patterns you know.


Extract all setup code to "helper" classes. This will help avoid copy/paste situations (I see devs copy/paste setup code for the test a lot).

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