I'm trying to create a test class which organizes its test methods using inner classes. I would like for this class to be abstract with the ability to set a static property so this property can be injected. Here's an example of what I'm talking about:
[TestClass]
public abstract class BaseUnitTest
{
public static string InjectedProperty;
public static string GetInjectedString()
{
return InjectedProperty;
}
[TestClass]
public class WhenFoo
{
[TestMethod]
public void TestFoo()
{
string str = GetInjectedString();
}
}
}
[TestClass]
public class DeriverdUnitTest : BaseUnitTest
{
[ClassInitialize]
public void SetUp()
{
InjectedProperty = "Injected Property";
}
}
However, I don't see a DerivedUnitTest+WhenFoo+TestFoo() class show up in my unit test view. I'm using Visual Studio 2010. I'm guessing when I override BaseUnitTest, I don't override its inner classes as well. I suppose I could make its inner classes abstract and override them later, but as the complexity of my test class increases this will get really annoying. Could somebody please explain why this is occuring and how I can fix it?
Thanks.
Edit:
I feel like I need to better explain my reasons for wanting to do this. We'd like to implement a testing standard which is very verbose in its naming. Therefore a test class would look something like this:
[TestClass]
public abstract class BaseUnitTest
{
public static string InjectedProperty;
public static string GetInjectedString()
{
return InjectedProperty;
}
[TestClass]
public class WhenFooIsCalled
{
[TestClass]
public class AndTheArgumentIsNull
{
[TestMethod]
public void AnArgumentNullExceptionShouldBeThrown()
{
string str = GetInjectedString();
}
}
}
}
The advantage of this is when you open up the test view in Visual Studio and display the method name and class name columns you get something that looks like this:
BaseUnitTest+WhenFooIsCalled+AndTheArgumentIsNull AnArgumentNullExceptionShouldBeThrown()
This makes it a lot easier to glance to tell what a failing test among a few hundred pass tests is supposed to do.
The main reason I want to be able to override the abstract BaseUnitTest is because when I do all of the tests which were contained in the BaseUnitTest are all added to the DerivedUnitTest and show up in the Test View in Visual Studio.
Thanks again.
In the C# language, nested classes have no special relationship with the class in which they are nested. It is a completely different type. There is only one good reason you'd ever do this: you can declare the class private. Which helps you to create a little worker class to get a job done on behalf of the outer class, a class that is completely invisible from the outside. Very useful, you cannot otherwise declare a private class at outer class scope, the best you can do is internal.
What follows is that it in no way plays a role in the inheritance of the outer class. A class you derive from the outer has no visibility to the nested class inside the base class at all. Which was the intention, declaring it private was the reason to nest it in the first place.
Punt: if you need that class in the derived one just declare it internal or public.
Nested types don't work that way. You can't "override" types.
It's not clear what you're trying to achieve here, but I don't think it's going to work.
You can accomplish the kind of rich, verbose, BDD-style test repriting with xUnit.NET and SubSpec. SubSpec is included in the xUnit.NET extras download these days. You can read more about SubSpec and BDD testing at the following article:
http://haacked.com/archive/2008/08/24/introducing-subspec.aspx
How about using a config file? For Example
[TestClass]
public class WhenFoo
{
[TestMethod]
public void TestFoo()
{
string str = ConfigurationManager.AppSettings["WhenFooTestFooString"];
}
}
Related
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.
I'm trying to write Unittests for D365 Plugins and CodeActivities (both being classes). There are small tests that should run in every plugin, such as:
[TestMethod]
public void NullLocalPluginContext()
{
XrmFakedContext context = new XrmFakedContext();
Assert.ThrowsException<InvalidPluginExecutionException>(
() => context.ExecutePluginWith<SomePlugin>(null));
}
Where SomePlugin is the class to be tested (which is for each child different) and cannot be abstract (awaits IPlugin). For example here it's a CheckDuplicateOrder in the child:
[TestClass]
public class CheckDuplicateOrderTest
{
[TestMethod]
public void NullLocalPluginContext()
{
XrmFakedContext context = new XrmFakedContext();
Assert.ThrowsException<Exception>(
() => context.ExecutePluginWith<CheckDuplicateOrder>(null));
}
}
For these small tests I'd like to have this parent with Shared tests but I don't know how to reference the 'to-be' child's target.
I prefer MSTest, but any NuGet framework is accepted.
Maybe this helps with understanding
Every plugin would have it's own test class.
Every plugintest class needs the basic.
These basic tests should be inherited from parent (so they don't take up space).
Plugins: Dog, Cat, Mouse
PluginTests: DogTest, CatTest, MouseTest
BasePluginTest -> should have shared tests where SomePlugin in the exmaple is Dog/Cat/Mouse. But I don't know how to reference it. Every plugin would have a function TestWalk() { .. ExecutePluginWith<SomePlugin>}. The Cat should call CatTest, the Dog should call DogTest.
As with a normal class you should favour composition over inheritance. Even
though test-classes do not have to follow the same rules and guidelines as normal classes doesn't mean we cannot implement them.
So when you feel you have some common functionality accross your test-classes you should extract some class that is used by your tests. You would do the same for a normal business-class also, won´t you?
class CommonFunc
{
public static bool NullLocalPluginContext<T, TException>() where T: IPlugIn, TException : Exception
{
XrmFakedContext context = new XrmFakedContext();
try { context.ExecutePluginWith<T>(null)) };
catch (T e) { return true; }
return false;
}
}
[TestClass]
public class CheckDuplicateOrderTests
{
[TestMethod]
public void NullLocalPluginContext()
{
Assert.IsTrue(CommonFunc.NullLocalPluginContext<CheckDuplicateOrder, Exception>(null));
}
}
[TestClass]
public class SomeOtherPluginTests
{
[TestMethod]
public void NullLocalPluginContext()
{
Assert.IsTrue(CommonFunc.NullLocalPluginContext<SomePlugin, InvalidPluginExecutionException>(null));
}
}
You could also make your common method rethrow the exception instead of just returning true or false if you want to log the actual exception being thrown within the test-framework.
Disclaimer: some people won't like this because it abuses class inheritance to save code. It's a potential tool for the job, you can evaluate whether it works for you or not.
This seems like it could be achievable with a base class to define the shared tests. Maybe something like this would achieve what you're trying to do?
// note: no [TestClass] on this type so it doesn't get discovered by MSTest.
// Probably should also be abstract.
public class SharedTests<T> where T : IPlugin
{
[TestMethod]
public void NullLocalPluginContext()
{
XrmFakedContext context = new XrmFakedContext();
Assert.ThrowsException<Exception>(
() => context.ExecutePluginWith<T>(null));
}
}
Your plugin classes would inherit from this class:
[TestClass]
public class CheckDuplicateOrderTests : SharedTests<CheckDuplicateOrder>
{
// NullLocalPluginContext test is inherited from the parent type
}
[TestClass]
public class SomeOtherPluginTests : SharedTests<SomeOtherPlugin>
{
// Also has NullLocalPluginContext test inherited, but for testing SomeOtherPlugin
}
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
}
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"));
}
I have the following code:
using System;
using NUnit.Framework;
using Rhino.Mocks;
public class A
{
}
public class B
{
}
public interface IStatementExecutor
{
void Exec(string statement);
}
public abstract class Foo<T>
{
private readonly IStatementExecutor _statementExecutor;
private readonly string _targetSegment;
protected Foo(IStatementExecutor statementExecutor, string targetSegment)
{
_statementExecutor = statementExecutor;
_targetSegment = targetSegment;
}
public void Update(T item)
{
_statementExecutor.Exec("sp_" + _targetSegment + "Update");
}
}
public class Bar : Foo<A>
{
public Bar(IStatementExecutor statementExecutor)
: base(statementExecutor, "ATable")
{
}
}
public class Baz : Foo<B>
{
public Baz(IStatementExecutor statementExecutor)
: base(statementExecutor, "BTable")
{
}
}
[TestFixture]
public class Foo_Tests
{
[Test]
public void Update_CallsStatementExecutorWithTableName()
{
const string tableName = "TestTable";
var mockStatementExecutor = MockRepository.GenerateMock<IStatementExecutor>();
mockStatementExecutor.Expect(m => m.Exec("sp_" + tableName + "Update"));
var sut = MockRepository.GeneratePartialMock<Foo<A>>(mockStatementExecutor, tableName);
var testModel = new A();
sut.Update(testModel);
mockStatementExecutor.AssertWasCalled(m => m.Exec("sp_" + tableName + "Update"));
}
}
I already have unit tests for the base class Foo<T>. Since the base class is already covered, I don't want to write identical tests for the derived classes Bar and Baz.
The only thing I really care about in the derived classes is that the correct string target is passed to the base class.
I'm struggling on how to unit test this without breaking encapsulation of the derived classes or writing redundant unit tests.
So, the question is, how do I test that the correct value gets passed to the base class from the derived classes for the target parameter?
(If your answer is "use composition...", please back it up with a code sample modified from above.
Thanks!
Think I'be more likely to test through the other methods on Bar and Baz, as you'd expect something bad to happen if you'd put ZTable in there instead of BTable
You could add a method to Foo that would return what ever had been passed to it
and then after creating the descendant call it and validate against the expected value.
Or you could do something like
public class Bar : Foo<A>
{
private static String _tableName = "ATable";
public String TableName {get {return _tableName;}}
public Bar() : base(_tableName)
{
}
}
Then you could test testBar.TableName
Another Option would be T was a struct or a class with a TableName property, then you wouldn't need Bar and Baz descendants, just for this.
Your Foo and Bar unit test methods could call helper methods that contain the common testing code.
You can do this in many ways. One way you could use a mocking framework like TypeMock to effectively mock the based class and thus get more information from TypeMock about internal variables.
It't not apparently clear from your post, though, why it's important that the base class be used in a specific why by the bar class. This isn't clear because you have no way of testing it. i.e. there's no external behaviour that you can monitor to guarantee Bar is using Foo in the expected way. You could redirect console output then monitor that output to do the verification. But, I don't think that's really what you're looking for.
You should provide an more testable example; something that doesn't just output text, something that had real behaviour that you can observe by a test.