This question already has an answer here:
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
ResetInitialized() visible only to the (unit) test assembly.
- 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.
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?