1

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);

}
Theresa
  • 3,515
  • 10
  • 42
  • 47
Yulia
  • 21
  • 3

2 Answers2

5

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.

Sergey Berezovskiy
  • 232,247
  • 41
  • 429
  • 459
  • I have to find way that unit tests will work in integrative namely dependent. This is my project. Maybe it Dependency injection or hierarchy.... – Yulia May 02 '14 at 14:33
  • @Yulia can you explain why you need tests to be dependent? – Sergey Berezovskiy May 02 '14 at 14:42
  • @ Sergey Berezovskiy I need to run all unit tests for integration form, but is not integration testing, name of my project is "reuse of unit tests for integration". It is maybe run all unit tests in hierarhy or output of one test is input other test, maybe i don't need to do refactoring to tests but i need to change my code of project. It is difficult to explain, i have one article it is explain my project. Maybe you write me your email and i send you this article. – Yulia May 02 '14 at 15:03
  • @Yulia sorry, need to go now, will be back in one hour. You can post link to article here – Sergey Berezovskiy May 02 '14 at 15:09
  • @ Sergey Berezovskiy http://www.agilerecord.com/agilerecord_16.pdf Article : Reuse of Unit Test Artifacts , page 49. – Yulia May 02 '14 at 15:22
  • @Yulia thanks, interesting magazine. But article you pointed is kind of *what if* dreaming, not something practical. Usually you start with integration/acceptance test when implementing user story. You write some scenarios and then you create unit tests for units which participate in this functionality. At the end of this process you have two different things - passing acceptance test and passing unit tests (which are very different from acceptance or integration tests). Don't try to use unit tests for integration testing – Sergey Berezovskiy May 02 '14 at 18:09
  • @ Sergey Berezovskiy Do you know how to use dependency injection with mock objects in this unit tests? – Yulia May 03 '14 at 16:54
0

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

Community
  • 1
  • 1