Yulia
Yulia

Reputation: 31

Dependency between two unit tests in c#

Suppose that we have two unit tests that are dependent on each other. TestA depends on TestB. Now we want to change the code so when we run TestA, TestB will automatically be run.

[TestMethod]
public void TestA()
{
    string id = "123456789";
    NewUser user = new NewUser();
    Boolean idCheck = user.checkID(id);
    Assert.IsFalse(idCheck);

}


[TestMethod]
[HostType("ASP.NET")]
[UrlToTest("http://localhost:1776/Login.aspx")]
[AspNetDevelopmentServerHost("$(SolutionDir)\\project", "/")]
public void TestB()
{
    Page page = _testContextInstance.RequestedPage;
    Button button = page.FindControl("BNewUser") as Button;
    PrivateObject po = new PrivateObject(page);
    po.Invoke("BNewUser_Click", button, EventArgs.Empty);
    Assert.IsFalse(page.Visible);

}

Upvotes: 2

Views: 1795

Answers (2)

Sergey Berezovskiy
Sergey Berezovskiy

Reputation: 236318

Unit tests should be F.I.R.S.T. Where I means isolated (not only from external resources, but from other tests also). TestB should have single reason to fail - if requirement which it verifies is not implemented. In your case it can fail if TestA was not run before, but requirement for TestB is implemented. So you never can tell real reason of test failure.

If you need some preconditions to be set before running TestB, then you should add this preconditions setting to Arrange part of TestB.

UPDATE: Reuse of Unit Test Artifacts. Allow Us to Dream article is just a dreaming of re-using unit tests for integration testing:

enter image description here

In theory it looks interesting. But in practice unit tests and integration tests are very different. First should be isolated latter are quite the reverse - they should use real dependencies and external resources. Lets imaging you will use some dependency injection framework to provide different implementations of dependencies to your SUT - mocked for unit-tests and real for integration tests. Sounds good. But it will make unit tests very hard to maintain - you will not know setup of mocked object in current test, because you are moving arrange part of test out of test to dependency injection framework. All unit tests will have only act and assert parts, which will have some value, but they will be really hard to understand and maintain.

Next part is even worth - how would you configure dependency injection framework to provide different setups of mocks for every different unit test? Also integration tests will require additional setup and tear-down steps which don't exist in separate unit-tests (you should clear and fill database etc). Also I can't even imagine how long it will take to run several thousands of integration tests which require real database, services and files. Unit tests use mocks, thus they are fast. Integration tests are slow.

As you can see, these types of tests are very different by their nature. So just don't try to mix them and use each one as it supposed to be used.

Upvotes: 5

user3585702
user3585702

Reputation: 16

I think you may want to use a common initialization for your unit test. You can validate the initialization inside of TestB before you continue.

Take a look at c# unit test with common code repeated this may answer your question.

As a rule, I hold the opinion that unit tests should not have dependencies, if you find that you cannot separate the two sets of functionality, you may consider re-factoring it.

Tim

Upvotes: 0

Related Questions