[TestMethod]
public void MyFunction_with_some_condition_does_something()
{
// Arrange
// 20 lines of setup code
...
// Act
...
// Assert
...
}
[TestMethod]
public void MyFunction_with_some_other_condition_does_something_else()
{
// Arrange
// The same 20 lines of setup code as above with one minor modification
...
// Act
...
// Assert
...
}
Of course the problem with this is that if you change one thing in your method's implementation, you may need to change every unit test, and it can get messy. This makes people lazy, and they will neither want to make changes, nor fix their unit tests. I'm not sure why people forget about good programming principles like DRY when it comes to unit tests. So you could do something like this, and keep your unit tests small (3 or 4 lines each), easy to read and change:
private MyFunctionRequest myFunctionRequest;
private void Arrange_MyFunction(bool condition1 = false, bool condition2 = false)
{
myFunctionRequest = new MyFunctionRequest
{
...
};
if(condition1)
{
...
}
}
[Test]
void MyFunction_with_some_condition_does_something_else()
{
// Arrange
Arrange_MyFunction(condition2:true);
// Act
target.MyFunction(myFunctionRequest)
// Assert
...
}
This looks okay, until you start to work with multiple methods in a class and find that you have to split your test class into regions and you have member variables that only pertain to a specific region. Using regions is often an indication that your class is doing more than it should. A better way to organise your tests is to have one class for each method being tested, like this:
[TestClass]
public class MyServiceTests
{
protected MyService target;
[TestInitialize]
public void Init()
{
target = new MyService();
}
[TestClass]
public class MyFunction_Method: MyServiceTests
{
private MyFunctionRequest request;
private void Arrange(bool condition1 = false, bool condition2 = false)
{
request = new MyFunctionRequest
{
//...
};
if (condition1)
{
//...
}
}
[TestMethod]
public void With_some_condition_does_something()
{
// Arrange
Arrange(condition1:true);
// Act
var actual = target.MyFunction(...);
// Assert
...
}
[TestMethod]
public void With_some_other_condition_does_something_else()
{
// Arrange
Arrange(condition2:true);
// Act
var actual = target.MyFunction(...);
// Assert
...
}
}
}
If your method being tested is particularly complicated, you could break it down even further, like this:
[TestClass]
public class MyServiceTests
{
protected MyService target;
[TestInitialize]
public void Init()
{
target = new MyService();
}
[TestClass]
public class MyFunction_Method: MyServiceTests
{
private MyFunctionRequest request;
[TestInitialize]
public void Init_MyFunction_Method()
{
request = new MyFunctionRequest();
}
[TestClass]
public class With_some_condition: MyFunction_Method
{
[TestMethod]
public void Does_something()
{
}
}
}
}
In Visual Studio, your solution explorer will look like this:
