I've read this article and a couple of others about testing and I think I've understand the theory but not the implementation in a real .NET project.
My project is decomposed in multiple (functional) assemblies and I wish to test it. Most of my methods and properties are private or internal so I can't access them from my test assembly. I only test the public one (in order to test all the paths of my assembly).
I'm wondering about the test I'm doing because these tests aren't unit-test because I'm using other services like a database, or other services like Microsoft HPC... Am I right ? In my opinion, if I want to do some unit test, I have to test private methods and properties, thing that is controversial.
I'm using Nunit and I was wondering if I could put integration test AND unit test in the framework ?
Is there any .NET opensource project with unit test and acceptance test that I could check out ?
Thanks
Many questions...
public/private: Typically, you only want to test through the public interface. If you want to test a private method it's probably a sign of that you should split the class into two and let the private methods become public (or internal). SRP. To test internal method, check this answer.
When writing a test you want to test the behaviour of the system. With behaviour, think of how the system behaves as seen from the end user (although there could be other interesting stakeholders as well). If you do this, you seldom encounter the problem with wanting to test private methods.
The difference between a unit test and an integration test is debated and, in my opinion, not a very important debate. What's more important is to ask yourself, what's the purpose of the test?
If your purpose is to test your system (as opposed to e.g. the integration with external systems), your tests should be repeatable, fast and not include anything you don't own. With repeatable I mean that, if the test fails once it should fail always (no randomness). With fast I mean that you should not have to wait too long for the feedback from running all your tests. With what you own I mean that the tests should not start failing due to changes made outside your organisation. If you can achieve this and still include calls to the database and/or Microsoft HPC, then I don't see any reason why not.
To differerentiate between different test types in NUnit you can use categories. Most tools allow you to run a subset based on these.
Collected from the Internet
Please contact [email protected] to delete if infringement.
Comments