Develop Reference

Grouping Unity NUnit tests?

I want to group tests like this:
To get this screenshot I used TestCases, but they don't really apply to my needs.
Obviously I don't want this:
[TestCase(TestName = "ShouldDoSomething")]
[TestCase(TestName = "ShouldDoSomethingElse")]
public void OnJoinRoom()
{ ... }
I want something like this:
[TestGroup("OnJoinRoom")]
public void ShouldDoSomething()
{ ... } 
[TestGroup("OnJoinRoom")]
public void ShouldDoSomethingElse()
{ ... } 
I don't think using subclasses is an option, as the tests are depending on a SetUp method used in the TestFixture class.

In NUnit, TestFixtures are used to group tests as well as to provide a common setup. The normal way to provide a common setup across multiple TestFixtures is to have a common base class like
public class CommonBase
{
[SetUp]
public void CommonSetUp() { }
}
[TestFixture]
public class OnJoinRoom : CommonBase { }
[TestFixture]
public class OnLeaveRoom : CommonBase { }
Notes:
Put all your tests in the derived classes
TestFixture attribute is optional, of course, but do not put it on the base class.
Base class may be abstract if you like.

NUnit 3.x - TestCaseSource for descendant test classes

I currently have a set of unit tests which are consistent for a number of Rest API endpoints. Say the class is defined like so.
public abstract class GetAllRouteTests<TModel, TModule>
{
[Test]
public void HasModels_ReturnsPagedModel()
{
// Implemented test
}
}
With the implemented test fixture looking like:
[TestFixture(Category = "/api/route-to-test")]
public GetAllTheThings : GetAllRouteTests<TheThing, ModuleTheThings> { }
This enables me to run a number of common tests across all GET all/list routes. It also means that I have classes which are linked directly to the module being tested, and links between tests and code in Resharper / Visual Studio / CI "just work".
The challenge is that some routes require query parameters for testing other pathways through the route code;
e.g. /api/route-to-test?category=big.
As [TestCaseSource] requires a static field, property, or method there appears to be no nice way to override a list of query strings to pass. The closest thing I have come up with seems like a hack. Namely:
public abstract class GetAllRouteTests<TModel, TModule>
{
[TestCaseSource("StaticToDefineLater")]
public void HasModels_ReturnsPagedModel(dynamic args)
{
// Implemented test
}
}
[TestFixture(Category = "/api/route-to-test")]
public GetAllTheThings : GetAllRouteTests<TheThing, ModuleTheThings>
{
static IEnumerable<dynamic> StaticToDefineLater()
{
// yield return all the query things
}
}
This works because the static method is defined for the implemented test class, and is found by NUnit. Huge hack. Also problematic for someone else consuming the abstract class as they need to "know" to implement "StaticToDefineLater" as a static something.
I am looking for a better way of achieving this. It seems like non-static TestCaseSource sources were removed in NUnit 3.x, so that's out.
Thanks in advance.
NOTES:
GetAllRouteTests<> implements a number of tests, not just the one shown.
Iterating through all the routes in one test will "hide" what is covered, so would like to avoid that.

The way I solved a similar problem is by having a base source class that implements IEnumerable (another acceptable source for NUnit), consider if this design suits your usecase:
// in the parent fixture...
public abstract class TestCases : IEnumerable
{
protected abstract List<List<object>> Cases { get; }
public IEnumerator GetEnumerator()
{
return Cases.GetEnumerator();
}
}
// in tests
private class TestCasesForTestFoobar : TestCases
{
protected override List<List<object>> Cases => /* sets of args */
}
[TestCaseSource(typeof(TestCasesForTestFoobar))]
public void TestFoobar(List<object> args)
{
// implemented test
}

Moq tell if function was called [duplicate]

I have a base class:
public abstract class MyBaseClass
{
protected virtual void Method1()
{
}
}
and a derived class:
public class MyDerivedClass : MyBaseClass
{
public void Method2()
{
base.Method1();
}
}
I want to write a unit test for Method2 to verify that it calls Method1 on the base class. I'm using Moq as my mocking library. Is this possible?
I came across a related SO link:
Mocking a base class method call with Moq
in which the 2nd answer suggests it can be achieved by setting CallBase property to true on the mock object. However it's not clear how this would enable the call to the base class method (Method1 in the above example) to be verified.
Appreciate any assistance with this.

Unit tests should verify behavior, not implementation. There are several reasons for this:
The results are the goal, not how you get the results
Testing results allows you to improve the implementation without re-writing your tests
Implementations are harder to mock
You might be able to put in hooks or create mocks that verify that the base method was called, but do you really care how the answer was achieved, or do you care that the answer is right?
If the particular implementation you require has side effects that you can verify, then that is what you should be validating.

Mocking the base class from the perspective of the derived class is not possible. In your simple example, I would suggest one of the two options.
Option 1: In the event that MyDerivedClass really shouldn't care what MyBaseClass is up to, then use dependency injection! Yay abstraction!
public class MyClass
{
private readonly IUsedToBeBaseClass myDependency;
public MyClass(IUsedToBeBaseClass myDependency){
_myDependency = myDependency;
}
public void Method2()
{
_myDependency.Method1();
}
}
Elsewhere in test land...
[TestClass]
public class TestMyDependency {
[TestMethod]
public void TestThatMyDependencyIsCalled() {
var dependency = new Mock<IUsedToBeBaseClass>();
var unitUnderTest = new MyClass(dependency.Object);
var unitUnderTest.Method2();
dependency.Verify(x => x.Method1(), Times.Once);
}
}
Option 2: In the event that MyDerivedClass NEEDS to know what MyBaseClass is doing, then test that MyBaseClass is doing the right thing.
In alternative test land...
[TestClass]
public class TestMyDependency {
[TestMethod]
public void TestThatMyDependencyIsCalled() {
var unitUnderTest = new MyDerivedClass();
var unitUnderTest.Method2();
/* verify base class behavior #1 inside Method1() */
/* verify base class behavior #2 inside Method1() */
/* ... */
}
}

What you're describing is not a test of your code, but a test of the behavior of the language. That's fine, because it's a good way to ensure that the language behaves the way we think it does. I used to write lots of little console apps when I was learning. I wish I'd known about unit testing then because it's a better way to go about it.
But once you've tested it and confirmed that the language behaves the way you expect, I wouldn't keep writing tests for that. You can just test the behavior of your code.
Here's a real simple example:
public class TheBaseClass
{
public readonly List<string> Output = new List<string>();
public virtual void WriteToOutput()
{
Output.Add("TheBaseClass");
}
}
public class TheDerivedClass : TheBaseClass
{
public override void WriteToOutput()
{
Output.Add("TheDerivedClass");
base.WriteToOutput();
}
}
Unit test
[TestMethod]
public void EnsureDerivedClassCallsBaseClass()
{
var testSubject = new TheDerivedClass();
testSubject.WriteToOutput();
Assert.IsTrue(testSubject.Output.Contains("TheBaseClass"));
}

TDD and inheritance

I am working on my first project using TDD and have hit a bit of a brick wall when it comes to inheritance.
For example if I have something like this
public interface IComponent
{
void MethodA();
void MethodB();
}
public class Component : IComponent
{
public virtual void MethodA()
{
// Do something
}
public virtual void MethodB()
{
// Do something
}
}
public class ExtendedComponent : Component
{
public override void MethodA()
{
base.MethodA();
// Do something else
}
}
then I cannot test ExtendedComponent in isolation because it depends on Component.
However, if I use composition to create ExtendedComponent like this
public class ExtendedComponent : IComponent
{
private readonly IComponent _component;
public ComponentB(IComponent component)
{
_component = component;
}
public virtual void MethodA()
{
_component.MethodA();
// Do something else
}
public virtual void MethodB()
{
_component.MethodB();
}
}
I can now test ExtendedComponent in isolation by mocking the wrapped IComponent.
The downside of this approach is that if I want to add new methods to IComponent then I have to add the new methods to Component and ExtendedComponent and any other implementations of which there could be many. Using inheritance I could just add the new method to the base Component and it wouldn't break anything else.
I really want to be able to test cleanly so am favouring the composition route but I am concerned that being able to unit test is not a valid reason to always use composition over inheritance. Also adding functionality at the base level will require the creation of lots of tedious delegating methods.
I'd really appreciate some advice on how other people have approached this kind of problem

your approach using composition is in all practicallity how most compilers implement inheritance so you gain nothing but pay a heavy cost (a lot of boilerplate code). So stick to the inheritance when there's a is-a relationship and composition when there is a has-a relation ship (those of course are neither gold nor the sole rules)

You don't need to worry about testing the extended component 'in isolation' because it does not 'depend' on component it IS a component (at least it is in the way you coded it).
All the tests you originally wrote for the component class are still fine and test all the unchanged behaviour in the extended class as well. All you need to do is write new tests that test the added functionality in the extended component.
public class ComponentTests{
[Fact]
public void MethodADoesSomething(){
Assert.xxx(new Component().MethodA());//Tests the component class
}
[Fact]
public void MethodBDoesSomething(){
Assert.xxx(new Component().MethodB());//Tests the component class
}
}
public class ExtendedComponentTests{
[Fact]
public void MethodADoesSomething(){
Assert.xxx(new ExtendedComponent().MethodA());//Tests the extended component class
}
}
You can see from above that MethodA functionality is tested for both the component AND the extended component. While the new functionality is only tested for the ExtendedComponent.

The key idea here is that one can have inheritance at unit test side too.
I use following approach in this scenario. I'll have a parallel inheritance hierarchy of unit test cases. e.g.
[TestClass]
public abstract class IComponentTest
{
[TestMethod]
public void TestMethodA()
{
// Interface level expectations.
}
[TestMethod]
public void TestMethodB()
{
// Interface level expectations.
}
}
[TestClass]
public class ComponentTest : IComponentTest
{
[TestMethod]
public void TestMethodACustom()
{
// Test Component specific test, not general test
}
[TestMethod]
public void TestMethodBCustom()
{
// Test Component specific test, not general test
}
}
[TestClass]
public class ExtendedComponent : ComponentTest
{
public void TestMethodACustom2()
{
// Test Component specific test, not general test
}
}
Each abstract test class or concrete class deals with expectations at it's own level. Thus extensible and maintainable.

You are correct - using composition over inheritance where it is not appropriate is not the way to go. Based on the information that you have provided here, it is not clear which is better. Ask yourself which one is more appropriate in this situation. By using inheritance, you get polymorphism and virtualization of methods. If you use composition, you are effectively separating your "front-end" logic from the isolated "back-end" logic -- this approach is easier in that changing the underlying component does not have a ripple effect on the rest of the code as inheritance often does.
All in all, this should not affect how you test your code. There are many frameworks for testing available, but this should not affect which design pattern you choose.

used in multiple [TestFixture]s

I'm in the process of setting up tests in NUnit and have a newbie question.
Is it possible to have a Test/s that could be used in multiple [TestFixture]s?
So
[Test]ValidateString(string bob)
Could be called in a series of different [TestFixture]?

That doesn't sound like a test to me. Tests are typically parameterless (unless you're using [TestCase]s) and running it within a context of a single fixture would typically be enough -- it either passes once and that's good or it doesn't and it's a broken test.
If you just have a method that does some validation on a string, you could set it up as a static method on some class (e.g. TestHelpers) and call it from whatever tests (in multiple test fixtures) need it.
Here's another idea: inheritance. You can have a base fixture that has all your tests, and then fixtures that inherit from it that set up whatever variables you need. The tests will run for each fixture. I'm not familiar with Selenium RC, but you should be able to adapt the code below to set up whatever variables you need in various fixtures.
[TestFixture]
public class BaseFixtureTests
{
protected IMyClass _myClass;
[TestFixtureSetUp]
public void FixtureSetup()
{
_myClass = ConfigureMyClass();
}
protected virtual IMyClass ConfigureMyClass()
{
// fixtures that inherit from this will set up _myClass here as they see fit.
}
[Test]
public void MyClassTest1()
{
// test something about _myClass;
}
}
[TestFixture]
public class MySpecificFixture1 : BaseFixtureTests
{
protected override IMyClass ConfigureMyClass()
{
return new MySpecificMyClassImplementation();
}
}
public class MySpecificMyClassImplementation : IMyClass
{
//some implementation
}
You can also add extra tests in each fixture as well that don't test common functionality and don't need to be reused across fixtures.

The newer version of NUnit supports generics. This is a great fit if what you are testing doesn’t need to be configured (only created) from your test code. Here is an example copied from http://nunit.net/blogs/:
[TestFixture(typeof(ArrayList))]
[TestFixture(typeof(List<int>))]
public class IList_Tests<TList> where TList : IList, new()
{
private IList list;
[SetUp]
public void CreateList()
{
this.list = new TList();
}
[Test]
public void CanAddToList()
{
list.Add(1); list.Add(2); list.Add(3);
Assert.AreEqual(3, list.Count);
}
}
I’ve also used Anna’s approach of inheritance. One possible refinement to her example (depending on personal preference): Don’t mark the base class as a TestFixture, only the child classes. Each class that you mark as a TestFixture will be displayed as a set of tests in the NUnit client. You will probably never want to run the base class methods directly because the child is providing all of the setup code. If you remove TestFixture from the base class, running invalid tests won’t be an option in the UI. This allows you to run all the tests and see all green… always a nice feeling.

You might be able to achieve what you want with inheritance.
using NUnit.Framework;
namespace ClassLibrary1
{
[TestFixture]
public class TestFixtureBase
{
[SetUp]
public virtual void Setup()
{
// setup code here
}
[Test]
public void CommonTest1()
{
Assert.True(true);
}
[Test]
public void CommonTest2()
{
Assert.False(false);
}
}
public class MyClassTests : TestFixtureBase
{
[SetUp]
public override void Setup()
{
base.Setup();
// additional setup code
}
[Test]
public void MyClassTest1()
{
Assert.True(true);
}
}
}

You can write a method to be called from multiple [Test] methods. But I don't think there is a way to have the same [Test] included in multiple [TestFixture]s.
[TestFixture]
public class TestsOne{
[Test] public void TryOne(){
Helpers.ValidateString("Work?");
}
}
[TestFixture]
public class TestsTwo{
[Test] public void TryTwo(){
Helpers.ValidateString("Work?");
}
}
public static class Helpers{
public static void ValidateString(string s){
Assert.IsNotNull(s);
}
}