Is it considered a bad coding practice to write methods/properties that support (only) testing? [duplicate]

Question

When I write (unit) tests I always try to avoid for example microsoft fakes because then the edit&continue feature no longer works. However this often requires refactoring... and sometimes methods or properties that exist only to support (unit) tests. An example:

With fakes I could do in each test method simply this:

ShimMyClass.InitializedGet = () => false;

but without fakes I need to write an internal method ResetInitialized() visible only to the (unit) test assembly.

---

As to:

• Would you rather make private stuff internal/public for tests, or use some kind of hack like PrivateObject?
• Is it a bad practice to modify code strictly for testing purposes

I won't make any private methods public to support unit testing but write them only for unit testing. Such methods would not have any other pupose but to be called in a unit test. ResetInitialized would never be called during a normal workflow but only by a unit test.

In other words: if I didn't create the unit test I would never have to write this additional helper method/property. It will never be called by anything other then a unit test.

---

Example

I have a class that I initialize when the application starts and subsequent initializations are skipped. The initialization takes place internally when the first feature is used. In this case I'm not able to test more then one test case at a time. I need to be able to reset it to let the tests run automatically.

Would it be bad to make it actually also resetable but the only user of this feature would be the unit test?

Answer 1

In other words: if I didn't create the unit test I would never have to write this additional helper method/property. It will never be called by anything other then a unit test.

A quick answer - you should not modify your source code to cater your tests.

Also rule of thumb: if a piece of code/method/class/functionality will never be called - remove it. Don't comment out, don't make it private - remove it.

However it is perfectly fine to write new mocks/stubs or fake method in your tests that would monkeypatch/overload/replace the original functionality.

Testsing/implementation should follow 80/20 rule meaning that approximatelly 80% of your development time will go on writing tests (unit, intergration, end-to-end, call any..) And it is completely obvious that if you are chaning the interface of your methods, then you will have to update your fakers or unit test structure.

Answer 2

Another answer: yes, you should absolutely modify your source code to cater to your tests.

Testing fulfills the function of improving and maintainig the quality of your code base. Therefore, making tests easier, or possible, to write, is a valid goal with positive business value, just like writing business code. It's logically inconsistent to spend time writing tests and simultaneously claiming that it is never justifiable to change business code for the sake of the test suite.

As always, this is a matter of trade-offs. Obviously you shouldn't make your code much less maintainable for a small improvement in test writing. But a small or zero expansion of the business code for a big improvement in test writing can absolutely be justified.

Lots of developers make the mistake of thinking that since test code isn't shipped to the customer, it's somehow not really part of the code base and needn't be as well-written and reliable as the business code. This couldn't be more wrong; we do testing solely because it helps us create better programs, so it cannot have zero value - otherwise it would be negligent of us to write any tests at all.

Answer 3

You need to make your code testable. That's rule number one. Anything else is pandering to the rabble who say, "we don't need no stinkin' tests."

If you need to re-initialize something, there is a possibility that the lifecycle for your code-under-test is the problem. When you create a new object instance, does it not cleanly initialize to the state you want?

If you have hidden state, you may have to add state-monitoring variables that are only used for testing.