Click here to Skip to main content
15,885,278 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
I want to know is it good idea to put Nunit code in same class that has to be
tested using unit tests. That is business logic & test code in same class.
Partial class feature can be used to put the test code in to another file.
May be some nested class to put actual testing code. And this code can be compiled conditionally. I want to do this because I believe this approach will make it possible to easily test private methods with Nunit. First I want to know is it possible? If yes what can be the problelms with this approach specially for large projects having continueous integration and stuff like that.
If its stupid question please tell me.
Posted
Comments
R. Erasmus 25-Mar-11 3:44am    
best to create unit test from an external class and setting up initial data, executing the class under tests respective methods and comparing the initial data with expected.
R. Erasmus 25-Mar-11 3:45am    
Having it in the same class will cost you to provide another test to show that the tested data does not affect the class itself.

Yes that will be possible. the only drawback I see the the readability and maintainability of the source code. that means your code will be messy if you combine the test codes and the actual code.
I hope this will help.
 
Share this answer
 
Comments
Prafulla Hunde 25-Mar-11 17:00pm    
Readability may not be so bad if the partial class definition is in separate file.Something like what visual studio does by making Form.Designer.cs to put all auto generated code. Also a separate inner test class can be used to put all testing code.
And all the code in the separate partial class file is compiled conditionally so it does not exist in release dlls.
Normally you would not apply unit testing to private methods. Unit testing is there to make sure that each component operates correctly according to its spec, i.e. the public interface works as it's supposed to. Testing private methods should generally be done on a less formal level, when you're developing them, with unit tests applied to the public output that the private methods help in constructing. That's one reason why most testing frameworks (including NUnit) don't have tricks to test non-public methods.

Unit testing your private methods means that you can't change how the class works internally without rewriting the tests, even if you haven't changed anything that is visible to the outside.

The answer to your question is that it should work, but it will be messy extracting the tests and the deployment and potentially confusing to people who visit the project after you.
 
Share this answer
 
Comments
Sergey Alexandrovich Kryukov 24-Mar-11 15:04pm    
Wise advice, my 5.
--SA
Prafulla Hunde 25-Mar-11 17:11pm    
I agree that the public interface has to be tested. But if one public method depends on n numbers of private methods to accomplish the task , then skipping them is also not a good idea.The one of the advantage of unit tests is to quickly figure out the failure when code is updated. If public method fails by updating any of private method it will take more time to figure out which one is causing problem. But if private methods are also have tests for them the fix may be quicker.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900