nunitmorganb/files/nunit.pdf · •stubs •mocks. filesystem dependency in logan public bool...
TRANSCRIPT
NUnit
Asserts
• Assert.AreEqual(expectedObject, actualObject, message);
• Assert.AreEqual(2, 1+1, "Math is broken");
• Assert.AreSame(expectedObject, actualObject, message);
• Parameterized Tests
• 1. Replace the [Test] attribute with the [TestCase] attribute.
• 2. Extract all the hardcoded values the test is using into parameters for the test method.
• 3. Move the values you had before into the braces of the [TestCase(param1, param2,..)] attribute.
• 4. Rename this test method to a more generic name.
• 5. Add a [TestCase(..)] attribute on this same test method for each of the tests you want to merge into this test method, using the other test’s values.
• 6. Remove the other tests so you’re left with just one test method that has multiple [TestCase] attributes.
After Step 4
[TestCase("filewithgoodextension.SLF")]
public void IsValidLogFileName_ValidExtensions_ReturnsTrue(string file)
{
LogAnalyzer analyzer = new LogAnalyzer();
bool result = analyzer.IsValidLogFileName(file);
Assert.True(result);
}
After Step 6
[TestCase("filewithgoodextension.SLF")][TestCase("filewithgoodextension.slf")]public void IsValidLogFileName_ValidExtensions_ReturnsTrue(string file){
LogAnalyzer analyzer = new LogAnalyzer();
bool result = analyzer.IsValidLogFileName(file);
Assert.True(result);}
Adding the Negative Test to [TestCase][TestCase("filewithgoodextension.SLF",true)][TestCase("filewithgoodextension.slf",true)][TestCase("filewithbadextension.foo",false)]public voidIsValidLogFileName_VariousExtensions_ChecksThem(string file, bool expected){
LogAnalyzer analyzer = new LogAnalyzer();
bool result = analyzer.IsValidLogFileName(file);
Assert.AreEqual(expected,result);}
[SetUp] and [TearDown] Attributes
•[SetUp] —This attribute can be put on a
method, just like a [Test] attribute, and it
causes NUnit to run that setup method each
time it runs any of the tests in your class.
•[TearDown] —This attribute denotes a
method to be executed once after each test
in your class has executed.
using NUnit.Framework;
[TestFixture]
public class LogAnalyzerTests {
private LogAnalyzer m_analyzer=null;
[SetUp]
public void Setup() {
m_analyzer = new LogAnalyzer();
}
[Test]
public void IsValidFileName_validFileLowerCased_ReturnsTrue() {
bool result = m_analyzer
.IsValidLogFileName("whatever.slf");
Assert.IsTrue(result, "filename should be valid!");
}
[Test]
public void IsValidFileName_validFileUpperCased_ReturnsTrue() {
bool result = m_analyzer
.IsValidLogFileName("whatever.SLF");
Assert.IsTrue(result, "filename should be valid!");
}
[TearDown]
public void TearDown()
{
//the line below is included to show an anti pattern.
//This isn’t really needed. Don’t do it in real life.
m_analyzer = null;
}
}
Having said that…
• Don’t use them. It makes test below harder to read.
• Use factory methods instead. We will see those later.
Checking for Expected Exceptions
public class LogAnalyzer {
public bool IsValidLogFileName(string fileName)
{
...
if (string.IsNullOrEmpty(fileName))
{
throw new ArgumentException(
"filename has to be provided");
}
...
}
}
If you send an empty filename –
• throw an ArgumentExceptionCode doesn’t throw an exception
• test should fail.
Two ways – this is 1, do not use
[Test]
[ExpectedException(typeof(ArgumentException),
ExpectedMessage ="filename has to be provided")]
public void IsValidFileName_EmptyFileName_ThrowsException()
{
m_analyzer.IsValidLogFileName(string.Empty);
}
private LogAnalyzer MakeAnalyzer()
{
return new LogAnalyzer();
}
This is 2 - do use
[Test]
public void IsValidFileName_EmptyFileName_Throws()
{
LogAnalyzer la = MakeAnalyzer();
var ex = Assert.Catch<Exception>(() => la.IsValidLogFileName(""));
StringAssert.Contains("filename has to be provided",
ex.Message);
}
Rare!, but useful
[Test]
[Ignore("there is a problem with this test")]
public void IsValidFileName_ValidFile_ReturnsTrue()
{
/// ...
}
Assert.That
[Test]
public void IsValidFileName_EmptyFileName_ThrowsFluent()
{
LogAnalyzer la = MakeAnalyzer();
var ex =
Assert.Catch<ArgumentException>(() =>
la.IsValidLogFileName(""));
Assert.That(ex.Message,
Is.StringContaining("filename has to be provided"));
}
Testing System State Change
DEFINITION
State-based testing (also called sate verification) determines whether the exercised method worked correctly by examining the changed behavior of the system under test and its collaborators (dependencies) after the method is exercised.
public class LogAnalyzer {
public bool WasLastFileNameValid { get; set; }
public bool IsValidLogFileName(string fileName) {
WasLastFileNameValid = false;
if (string.IsNullOrEmpty(fileName)) {
throw new ArgumentException("filename has to be provided");
}
if (!fileName.EndsWith(".SLF",
StringComparison.CurrentCultureIgnoreCase)) {
return false;
}
WasLastFileNameValid = true;
return true;
}}
Testing a Class by Calling a Method and Checking the Value of a Property
[Test]
public void
IsValidFileName_WhenCalled_ChangesWasLastFileNameValid()
{
LogAnalyzer la = MakeAnalyzer();
la.IsValidLogFileName("badname.foo");
Assert.False(la.WasLastFileNameValid);
}
Test for the Opposite Expectation of the System State[TestCase("badfile.foo", false)]
[TestCase("goodfile.slf", true)]
public void
IsValidFileName_WhenCalled_ChangesWasLastFileNameValid(string file,
bool expected)
{
LogAnalyzer la = MakeAnalyzer();
la.IsValidLogFileName(file);
Assert.AreEqual(expected, la.WasLastFileNameValid);
}
Another Example - MemCalculator
public class MemCalculator {
private int sum=0;
public void Add(int number) {
sum+=number;
}
public int Sum() {
int temp = sum;
sum = 0;
return temp;
}
}
The Simplest Test for a Calculator’s Sum()
[Test]
public void Sum_ByDefault_ReturnsZero()
{
MemCalculator calc = new MemCalculator();
int lastSum = calc.Sum();
Assert.AreEqual(0,lastSum);
}
Simple List of Naming Conventions of Scenarios
can be used when there’s an expected return value
with no prior action, as shown in the previous example.
or
can be used in the second or third kind of unit
of work results (change state or call a third party) when the state
change is done with no prior configuration or when the third-party
call is done with no prior configuration; for example,
Sum_WhenCalled_CallsTheLogger or Sum_Always_CallsTheLogger.
ByDefault
AlwaysWhenCalled
Two Tests, With the Second One Calling the Add() Method[Test]
public void Sum_ByDefault_ReturnsZero() {MemCalculator calc = MakeCalc();int lastSum = calc.Sum();Assert.AreEqual(0, lastSum);
}
[Test]
public void Add_WhenCalled_ChangesSum() {MemCalculator calc = MakeCalc();calc.Add(1);int sum = calc.Sum();
Assert.AreEqual(1, sum);
}
//Factory method to initialize MemCalculatorprivate static MemCalculator MakeCalc() {
return new MemCalculator();}
External Dependencies and Stubs
• DEFINITION
• An external dependency is an object in your system that your code under test interacts with and over which you have no control. (Common examples are filesystems, threads, memory, time, and so on.)
DEFINITION
• A stub is a controllable replacement for an existing dependency (or collaborator) in the system. By using a stub, you can test your code without dealing with the dependency directly.
Test Pattern Names
• Fakes
• Stubs
• Mocks
Filesystem Dependency in LogAn
public bool IsValidLogFileName(string fileName){//read through the configuration file//return true if configuration says extension is supported.}
Layer of Indirection
1. Find the interface that the start of the unit of work under test works against.
2. If the interface is directly connected to your unit of work under test (as in this case—you’re calling directly into the filesystem), make the code testable by adding a level of indirection hiding the interface.
3. Replace the underlying implementation of that interactive interface with something that you have control over.
Refactoring your design to be more testableDEFINITION
• Refactoring is the act of changing code without changing the code’s functionality.
DEFINITION
• Seams are places in your code where you can plug in different functionality, such as stub classes.
Dependency Breaking Refactorings
• Extract an interface to allow replacing underlying implementation.
• Inject stub implementation into a class under test.
• Receive an interface at the constructor level.
• Receive an interface as a property get or set.
• Get a stub just before a method call.
Extract an interface to allow replacing underlying implementation.
Extracting an interface from a known class
The Stub Extension Manager (that always returns true)public class AlwaysValidFakeExtensionManager:IExtensionManager
{
public bool IsValid(string fileName)
{
return true;
}
}
Inject stub implementation into a class under test• Receive an interface at the constructor level and save it in a field for
later use.
• Receive an interface as a property get or set and save it in a field for later use.
• Receive an interface just before the call in the method under test using one of the following:
• A parameter to the method (parameter injection)
• A factory class
• A local factory method
• Variations on the preceding techniques
Receive an interface at the constructor level (constructor injection)
Mock
State-based testing vs interaction testing
• State-based testing (also called state verification) determines whether the exercised method worked correctly by examining the state of the system under test and its collaborators (dependencies) after the method is exercised. (result-driven testing)
• Interaction testing is testing how an object sends input to or receives input from other objects—how that object interacts with other objects. (action based testing)
Definition
• A mock object is a fake object in the system that decides whether the unit test has passed or failed. It does so by verifying whether the object under test interacted as expected with the fake object. There’s usually no more than one mock per test.
The difference between mocks and stubs
Create the Interface
public interface IWebService
{void LogError(string message);
}
Create the Mock
public class MockService:IWebService
{
public string LastError;
public void LogError(string message)
{
LastError = message;
}
}
Using an Isolation Framework
Definition
• An isolation framework is a set of programmable APIs that make creating mock and stub objects much easier. Isolation frameworks save the developer from the need to write repetitive code to test or simulate object interactions. Examples of isolation frameworks are NMock, Moq, Typemock Isolator, and Rhino Mocks.
Definition
• A dynamic fake object is any stub or mock that’s created at runtime without needing to use a handwritten implementation of an interface or subclass.
Moq
From the NuGet console –
Install-Package Moq –version 4.1.1309.1627 –projectnameyourprojectname.Tests