Develop Reference

Share variable value between tests in Xunit test [duplicate]

I have written the xUnit test cases in C#. That test class contains so many methods. I need to run the whole test cases in a sequence. How can I set the test case sequence in xUnit?

In xUnit 2.* this can be achieved using the TestCaseOrderer attribute to designate an ordering strategy, which can be used to reference an attribute that is annotated on each test to denote an order.
For example:
Ordering Strategy
[assembly: CollectionBehavior(DisableTestParallelization = true)]
public class PriorityOrderer : ITestCaseOrderer
{
public IEnumerable<TTestCase> OrderTestCases<TTestCase>(IEnumerable<TTestCase> testCases) where TTestCase : ITestCase
{
var sortedMethods = new SortedDictionary<int, List<TTestCase>>();
foreach (TTestCase testCase in testCases)
{
int priority = 0;
foreach (IAttributeInfo attr in testCase.TestMethod.Method.GetCustomAttributes((typeof(TestPriorityAttribute).AssemblyQualifiedName)))
priority = attr.GetNamedArgument<int>("Priority");
GetOrCreate(sortedMethods, priority).Add(testCase);
}
foreach (var list in sortedMethods.Keys.Select(priority => sortedMethods[priority]))
{
list.Sort((x, y) => StringComparer.OrdinalIgnoreCase.Compare(x.TestMethod.Method.Name, y.TestMethod.Method.Name));
foreach (TTestCase testCase in list)
yield return testCase;
}
}
static TValue GetOrCreate<TKey, TValue>(IDictionary<TKey, TValue> dictionary, TKey key) where TValue : new()
{
TValue result;
if (dictionary.TryGetValue(key, out result)) return result;
result = new TValue();
dictionary[key] = result;
return result;
}
}
Attribute
[AttributeUsage(AttributeTargets.Method, AllowMultiple = false)]
public class TestPriorityAttribute : Attribute
{
public TestPriorityAttribute(int priority)
{
Priority = priority;
}
public int Priority { get; private set; }
}
Test Cases
[TestCaseOrderer("FullNameOfOrderStrategyHere", "OrderStrategyAssemblyName")]
public class PriorityOrderExamples
{
[Fact, TestPriority(5)]
public void Test3()
{
// called third
}
[Fact, TestPriority(0)]
public void Test2()
{
// called second
}
[Fact, TestPriority(-5)]
public void Test1()
{
// called first
}
}
xUnit 2.* ordering samples here

Testpriority: at the bottom of this page.
[PrioritizedFixture]
public class MyTests
{
[Fact, TestPriority(1)]
public void FirstTest()
{
// Test code here is always run first
}
[Fact, TestPriority(2)]
public void SeccondTest()
{
// Test code here is run second
}
}
BTW, I have the same problem right now. And yes, it is not the clean art.. but QA wanted a manual test.. so an automated test with a specific order already is a big leap for them.. (cough) and yes, it is not really unit testing..

If you really have the need to prioritize your tests (probably not your unit tests) you can use Xunit.Priority.
I have used it for some integration testing and works really well and simple without the overhead of having to write your prioritization classes, for simple case scenarios

For some reason, XUnit.Priority didn't work for me. In my test cases, it wasn't running the tests in the priority order specified.
So I tried XUnitPriorityOrderer, which is similar to use but was working (To quickly test it, save the following code in a text editor as OrderedXUnitTests.linq, then open it with LinqPad 6 and execute it. Alternatively, you can also copy the TestClass to Visual Studio and add XUnit, XUnit.Runner.VisualStudio and XUnitPriorityOrderer):
<Query Kind="Program">
<NuGetReference>XUnitPriorityOrderer</NuGetReference>
<Namespace>Xunit</Namespace>
<Namespace>XUnitPriorityOrderer</Namespace>
</Query>
#load "xunit"
// using XUnitPriorityOrderer
// see: https://github.com/frederic-prusse/XUnitPriorityOrderer
void Main()
{
RunTests(); // Call RunTests() or press Alt+Shift+T to initiate testing.
}
#region private::Tests
[TestCaseOrderer(CasePriorityOrderer.TypeName, CasePriorityOrderer.AssembyName)]
public class TestClass
{
static List<string> Order { get; set; }
public TestClass()
{
Order = Order ?? new List<string>();
}
[Fact, Order(2)]
void Test_Xunit_AnotherTest()
{
Order.Add("Test_Xunit_AnotherTest");
Assert.True(3 + 1 == 4);
}
[Fact, Order(1)]
void Test_Xunit()
{
Order.Add("Test_XUnit");
Assert.True(1 + 1 == 2);
}
[Fact, Order(99)]
void Print_Order()
{
Order.Add("Print_Order");
var strOrder = string.Join(", ", Order.ToArray());
strOrder.Dump("Execution Order");
Assert.True(true);
}
}
#endregion
This will run the tests in given order (Order(1), Order(2) and then Order(99)) and will dump the executed tests finally (test method Print_Order()).

You can't, by design. It's deliberately random in order to prevent anyone getting one of those either by desire or by accident.
The randomness is only for a given Test class, so you may be able to achieve your goals by wrapping items you want to control the order of inside a nested class - but in that case, you'll still end up with random order whenever you have more than two Test Methods in a class.
If you're trying to manage the building up of fixtures or context, the built-in IUseFixture<T> mechanism may be appropriate. See the xUnit Cheat Sheet for examples.
But you really need to tell us more about what you're trying to do or we'll just have to get speculative.

Is there a way to utilize a variable defined in an nUnit [Test] in subsequent tests in a [TestFixture]?

I am converting a JMeter TestPlan into nUnit using RestSharp to consume API calls. My goal is to merge these tests into my visual studio project solution.
My problem is, many of the API calls in the JMeter's Test Plan are extracting key/values from their JSON response which are then used in subsequent test's requests.
My question is, is it possible in nUnit/RestSharp to define variables from a test's response that can be used in subsequent tests within a [TestFixture]? Or will these variables have to be redefined under every [Test]?

Use an [Order(n)] attribute to run the tests in order, and I'd just use a private object to store the variables between tests. So something like:
[TestFixture]
public class Tests
{
private int valueBeingPassed;
[OneTimeSetUp]
public void Setup()
{
valueBeingPassed = 1;
}
[Test, Order(1)]
public void Test1()
{
valueBeingPassed += 2;
Assert.AreEqual(valueBeingPassed, 3);
}
[Test, Order(2)]
public void Test2()
{
var doubleValue = valueBeingPassed * 2;
Assert.AreEqual(doubleValue, 6);
}
}

Testing member assignment using mocks in c#

I am writing a testing framework for my system, which allows users to create mocked inputs to the system. The system manipulates that input, and updates some of its members for later post processing.
In order to allow users to mock the input, I need to be able to update a mocked input's members. Furthermore, the input may not be a mock, so I would prefer a solution oblivious to the type of element received.
Simply put, I have a function which receives an object and attempts to set one of its properties:
func(object a)
a.m = 5;
Which I want to test by mocking its input a, using the Moq library. Unfortunately, my test failed, since mocked objects' members need to be set using Mock.SetUpGet, instead of standard member assignment.
What would be a good way to test such a function, without changing it?

In order to be able to mock and test it, the property must be virtual, but if that's the case you can use the SetupSet method, rather than SetupGet:
public class A
{
public virtual int m { get; set; }
}
[TestFixture]
public class Tests
{
public static void SetProperty(A a)
{
a.m = 5;
}
[Test]
public void IsThePropertySet()
{
var x = new Mock<A>();
x.SetupSet<int>(a => a.m = 5).Verifiable();
SetProperty(x.Object);
x.Verify();
}
}

Your function should have getters and setters anyway.
And a good way of testing whether your functions work is to do a small-scale test. Initialize an object and send that in to your method, seeing whether it does what you want.
public class myClass
{
public int number;
public void setNumber(int nNum)
{
number = nNum;
}
public int getNumber()
{
return number;
}
}
class Program
{
static void myMethod(myClass obj, int nNumb)
{
//obj.setNumber(nNumb);
obj.number = nNumb;
}
static void Main(string[] args)
{
myClass myObj = new myClass();
myMethod(myObj, 3);
//Console.WriteLine(myObj.getNumber());
Console.WriteLine(myObj.number);
Console.ReadLine();
}
}
}
Output: 3

Test a public method which calls a private method using NUnit

I have a public method in a class that internally calls a particular private method within that class. It looks something like this :
public class MyClass : IMyClassInterface
{
public List<int> MyMethod(int a, int b)
{
MyPrivateMethod(a, b, ref varList, ref someVal);
}
private void MyPrivateMethod(int a, int b, ref List<int> varList, ref double someval)
{
}
}
Now, I basically want to test this public method using NUnit. I am using NMock 2.0 for mocking. How do I do it? Since, it internally calls this private method which I do not want to make public. Or is there a way to do it if I turn the private method to protected instead?

Now, I basically want to test this public method (...)
This is great. This is what you should be doing. Forget about internal details for a moment. From public method point of view, is there any difference between these two snippets?
// Your current implementation
public void MyMethod(int a, int b)
{
MyPrivateMethod(a, b);
}
private void MyPrivateMethod(int a, int b)
{
var c = a + b;
// some more code
}
// Private method inlined
public void MyMethod(int a, int b)
{
var c = a + b;
// some more code
}
Whoever calls (public) MyMethod will not be able to notice any difference between these two. End result is the same. It doesn't matter there is a private method call, because as far a public API is concerned it is irrelevant. You could inline said private method, make it gone forever, and from public consumer point of view nothing changes. End result is the only thing that's important. You test end result observable by code consumer. Not some internal gibberish.
Important realization is this:
Properly designed SOLID code will never put you in a position which will require you to do private mocking. Source of the problem? Bad design.
Source: How to mock private method - solutions
Yep. Sad but true, your design is not that great. Depending on whether you want to change that or not, there are few approaches you could take:
don't try to mock private details, focus on public API (doesn't help with design issue)
extract private method to class, introduce dependency (long-term solution, improves design and makes code easily testable)
make private method protected, override in test as suggested in other answer (doesn't help with design issue, might not yield valuable test)
Whichever you chose I leave up to you. However, I'll emphasize it one more time - mocking private method is not unit testing, library or tools problem - it is a design problem and is best solvable as such.
On a side note, (if you can) don't use NMock2. It's a library with last changes from 2009. It's like having a 30 year old car which was last serviced 15 years ago. There are much better ones nowadays (FakeItEasy, Moq, NSubstitute).

Yes the "trick" is to use protected instead of private and then inherit the class and run the test on the new class that executes the protected method.
This is a very common way to make brownfield and legacy code testable.
[TestClass]
public class UnitTest1
{
[TestMethod]
public void TestMethod1()
{
MyClassTestWrapped t = new MyClassTestWrapped();
Assert.IsTrue(t.MyPrivateMethod(...));
Assert.IsTrue(t.MyMethod(...));
MockFactory _factory = new MockFactory();
Mock<MyClassTestWrapped> mock;
mock = _factory.CreateMock<MyClass>();
mock.Expects.One.MethodWith(d => d.MyPrivateMethod()); // do the nmock magic here
}
}
public class MyClass : IMyClassInterface
{
public List<int> MyMethod(int a, int b)
{
MyPrivateMethod(a, b, ref varList, ref someVal);
}
// here change to protected
protected void MyPrivateMethod(int a, int b, ref List<int> varList, ref double someval)
{
}
}
public interface IMyClassInterface
{
}
public class MyClassTestWrapped : MyClass
{
public List<int> MyMethod(int a, int b)
{
base.MyMethod(a, b);
}
public List<int> MyPrivateMethod(int a, int b,ref List<int> varList, ref double someval)
{
base.MyPrivateMethod(a, b, ref varList, ref someval);
}
}

While currently you have to refactor your code to lose the private modifier ( wrappers and what not), You can do it fairly easy with tools Like Typemock Isolator.
I added some code to your example to write the test:
public class MyClass
{
public List<int> MyMethod(int a, int b)
{
List<int> varList = new List<int>();
double someVal = 0;
MyPrivateMethod(a, b, ref varList, ref someVal);
return varList;
}
private void MyPrivateMethod(int a, int b, ref List<int> varList, ref double someval)
{
}
}
With this straight forward approach you just fake the private method as it is in your code (no changes in the production), even it's ref parameters:
[Test]
public void TestMethod1()
{
//Arrange
var myClass = new MyClass();
var expectedVarList = new List<int> {1,2,3};
Isolate.NonPublic.WhenCalled(myClass, "MyPrivateMethod")
.AssignRefOut(expectedVarList, 0.0)
.IgnoreCall();
//Act
var resultVarList = myClass.MyMethod(0, 0);
//Assert
CollectionAssert.AreEqual(expectedVarList, resultVarList);
}

What is purpose of mocking a class like Calculator?

I've been using TDD for some time but now I'm looking at mocking frameworks and I don't get some things. This question might sound stupid for someone experienced but I just don't get it. The library I use is Moq + xUnit.
Question
What's the point of testing Calculator class if I explicitly say that 2 + 2 will return 4 on this line mock.Setup(x => x.Add(2, 2)).Returns(4); and then assert it?
Of course result will be 4, I just "forced" it to return 4 in few lines above the test itself. And now even in my implementation if I do return a * b; instead of return a + b; the test will pass.
Here is another example of this same calculator tests. http://nsubstitute.github.io/
Example Code
namespace UnitTestProject1
{
using Xunit;
using Moq;
public class CalculatorTests
{
private readonly ICalculator _calculator;
public CalculatorTests()
{
var mock = new Mock<ICalculator>();
mock.Setup(x => x.Add(2, 2)).Returns(4);
mock.Setup(x => x.Subtract(5, 2)).Returns(3);
this._calculator = mock.Object;
}
[Fact]
public void Calculator_Should_Add()
{
var result = _calculator.Add(2, 2);
Assert.Equal(4, result);
}
[Fact]
public void Calculator_Should_Subtract()
{
var result = _calculator.Subtract(5, 2);
Assert.Equal(3, result);
}
}
public class Calculator : ICalculator
{
public int Add(int a, int b)
{
return a + b;
}
public int Subtract(int a, int b)
{
return a - b;
}
}
public interface ICalculator
{
int Add(int a, int b);
int Subtract(int a, int b);
}
}

The purpose is to be able to test classes depending on calculator without having the calculator is self. In your test you know that the calculator can't be the cause of failure, because is returning the correct answer.
By isolating the code under test you will be able to test real units of code. And also see exactly what is causing your test failure.

You should not unit test the mock.
Suppose you want to test an object OrderProcessor which uses IService and IStorage.
To "Unit Test" OrderProcessor you simulate the behavior of IService and IStorage so that you can verify that your target class works as expected without using a Web Service and a Database.
I.e.
class OrderProcessor{
private IService service, IStorage storage;
public OrderProcessor(IService service, IStorage storage){ // bla bla}
public ProcessOrder(Order o){
// do something
// use the service
var price = service.GetPrice(..);
// store the result
storage.StoreOrder(order);
}
}
// test. Define mocks
var mockStorage = new Mock<IStorage>();
var mockService = new Mock<IService>();
// Setup test behaviour
mockStorage.Setup(m => m.GetPrice("X10").Returns(11);
mockStorage.Setup(m => m.GetPrice("X11").Returns(99);
...
var target = new OrderProcessor(mockService.Object, mockStorage.Object);
// ...
target.ProcessOrder(o);
// Verify the storing was called
mockStorage.Verify(m => m.StoreOrder(o), Times.Once());
// Verify the service was called X times
mockService .Verify(m => m.GetPrice(x), Times.Exactly(order.Items.Count));

In this case, there's no point in mocking -- the example is too simple. You're not gaining anything by mocking ICalculator.
You mock when you have a complex implementation, and you're trying to test something that depends on an implementation of that interface. You're not doing that in this case, you're testing a mock implementation. Testing a mock implementation is pointless.
For example, let's say your calculator implementation actually made a call to a web service to perform the calculations, and you were trying to test something that consumed calculations from the service. Your goal isn't to test the calculator -- your goal is to test the thing that uses the calculator. Having your test depend on a web service being up and running is silly, and could lead to your test failing unexpectedly.

Mocks are used in place of dependencies.
For example:
public interface IAddModule
{
int Add(int lhs, int rhs);
}
public class Calculator
{
private readonly IAddModule _addModule;
public Calculator(IAddModule addModule)
{
_addModule = addModule;
}
public int Add(int lhs, int rhs)
{
return _addModule.Add(lhs, rhs);
}
}
The Calculator class depends on the IAddModule. Depending on how IAddModule is implemented it might have side effects like logging or unmanaged code. To isolate the dependency you use a Mock in place of the IAddModule to test the class.
public class CalculatorTests
{
private readonly Calculcator _calculator;
public CalculatorTests()
{
var mock = new Mock<IAddModule>();
mock.Setup(a => a.Add(2, 2)).Returns(4);
_calculator = new Calculator(mock.Object);
}
[Fact]
public void Given_2_And_2_Then_4_Is_Returned()
{
var result = _calculator.Add(2, 2);
Assert.Equal(4, result);
}
}