I create my compact test database. This is a SDF file, embedded as a visual studio resource. When test suite starts this database is copied in %LOCALAPPDATA% so my test can use it.
The first method that I want to test is the getById method. Pretty simple.
var response = repo.GetById(IdToFind)
Assert.IsNotNull(response);
Now suppose I want to test the Remove method. These are the steps that I figure out:
repo.Remove(objectToRemove)
var response = repo.GetById(objectToRemove.Id) // is this a right choice?
Assert.IsNull(response);
this seems pretty clear to me, except for the GetById call. Does this step undermine test atomicity?
In general, you can’t test each method separately. At a minimum, each test will be testing both a constructor and the method you actually call. For methods that change the state, you are going to have to investigate the state afterwards. You can either have the test depend on implementation details by looking into the internal state of the object, or you can have your test depend on both pieces of functionality. Having your test depend on the details of internal state is much worse then testing too much functionality together.
Short answer – yes it does. If you test remove with something that involves getById and test getById with something that involves remove then both may fail simultaneously and you will not get any indication.
The straightforward solution is to just not use any other functions in the test. For example – by using plaintext queries – since you know your test DB structure and exactly what you expect. This will become a maintenance nightmare if you migrate DBs though.
Another is to have a set of basic methods that are tested using proper tests that don’t invoke any other methods and just use an elaborate setup. It is then OK to use these tested methods in more complex tests of other functions. Usually these “basic” functions form a special class as well (and that’s a plus, since anyone new to your environment will not know about this setup and testing mode for some but not other methods of a class).