CODEWITHSUNDEEP
c#.netunit-testingtddintegration-testing
amateur
amateur

Reputation: 44663

assistance with classifying tests

I have a .net c# library that I have created that I am currently creating some unit tests for. I am at present writing unit tests for a cache provider class that I have created. Being new to writing unit tests I have 2 questions These being:

  1. My cache provider class is the abstraction layer to my distributed cache - AppFabric. So to test aspects of my cache provider class such as adding to appfabric cache, removing from cache etc involves communicating with appfabric. Therefore the tests to test for such, are they still categorised as unit tests or integration tests?

  2. The above methods I am testing due to interacting with appfabric, I would like to time such methods. If they take longer than a specified benchmark, the tests have failed. Again I ask the question, can this performance benchmark test be classifed as a unit test?

The way I have my tests set up I want to include all unit tests together, integration tests together etc, therefore I ask these questions that I would appreciate input on.

Upvotes: 2

Views: 128

Answers (2)

Matt
Matt

Reputation: 14541

  1. These would likely be considered integration tests since you aren't testing code in isolation, but rather the integration of at least two different classes of production code. If you had the class(es) of AppFabric implement interface(s) and then test your cache provider class using stubs and/or mocks that impliment the interface(s), then this would be considered a unit test.

  2. Michael Feathers defines 1/10th a second or longer as too slow for a unit test in his book Working Effectively With Legacy Code, page 13. While it may technically be implemented as a unit test, you'll likely want to run these tests with integration tests, which also tend to take longer to execute.

    The reason is that if you have thousands of tests (say 10,000) and they take 1/10th a second each, you're looking at about 17 minutes to run them. If you have your tests run every time you commit your latest changes (so as to get quick feedback if you break something), that would likely be too long. This doesn't mean you shouldn't write slower unit tests, you may need them, but it just means you won't want to run them as often as the faster unit tests as the project grows.

    I also wouldn't make them fail if they take to long as their timings will likely vary from run to run to some degree. If they are generally slower, group them with the integration tests.

    Further, Feathers summarizes on page 14:

    Unit tests run fast. If they don't run fast, they aren't unit tests.

    Other kinds of tests often masquerade as unit tests. A test is not a unit test if:

    1. It talks to a database.
    2. It communicates across a network.
    3. It touches the file system.
    4. You have to do special things to your environment (such as editing configuration files) to run it.

Upvotes: 2

jorgehmv
jorgehmv

Reputation: 3713

if you have to depend on other class/component then it cannot be unit test, you are testing the class integration with other part of your system.

I would not advice to test performance this way, since the same test against the same code would fail or succeed depending on external factors. A profiler is the way to go IMO

Upvotes: 1

Related Questions