DeploymentItem doesn't work with TestInitialze() - visual-studio-2010

I need to copy some directories/files for MS Unit test, and I have this code.
[TestInitialize()]
[DeploymentItem("\\library", "library")]
public void Initialize()
{
....
}
The problem is that the directory/files are not copied with [TestInitialize()], I needed to use as follows:
[TestMethod]
[DeploymentItem("\\library", "library")]
public void AddInt16()
{
...
}
Am I supposed to use DeploymentItem only with [TestMethod]? If not, what's wrong with my code?

You can use it at a method or class level:
[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method, AllowMultiple = true)]
public sealed class DeploymentItemAttribute : Attribute
so, a good workaround given that its not picked up by TestInitialize is to move the DeploymentItem to your class.

Either define the deployment item at class level or at the .testrunconfig file.

Related

Equivalent of generic NUnit.Framework.TestFixture in xUnit

In NUnit, we can create a generic test fixture.
[TestFixture(typeof(double))]
[TestFixture(typeof(float))]
public class ServiceTests<T>
{
private readonly MyService<T> myService = new();
/* ... */
}
Has xUnit any equivalent of this?
I'm trying to test a generic service and now I need to create separate classes to test it for many generic types.
public abstract class DoubleServiceTests : ServiceTests<double>
{}
public abstract class FloatServiceTests : ServiceTests<float>
{}
public abstract class ServiceTests<T>
{
private readonly MyService<T> myService = new();
/* ... */
}
This is a solution that I'm currently using.
Maybe usage of Theory attribute will help.
Theory allows injection of test data inside a test. So some test from ServiceTests may look like this:
[Theory]
[InlineData(typeof(float))]
[InlineData(typeof(double))]
public void SomeTestMethod(Type t)
{
// make use of type t
}
More [info] on Theory related attributes in xunit.

Error if the [AssemblyInitialize] already exists in the test project with Specflow

I've updated Specflow from the 3.0.225 to the 3.1.62 and I received the error Tests_Integration_MSTestAssemblyHooks: Cannot define more than one method with the AssemblyInitialize attribute inside an assembly.
The reason is obviously that I'd had the [AssemblyInitialize] attribute in my project already. How can I fix it?
The reason is that Specflow generates another file in the background which has the AssemblyInitialize/AssemblyCleanup hooks defined. In order to fix that one should use the hooks provided by Specflow, namely BeforeTestRun/AfterTestRun. Like this:
[Binding] // add the Binding attribute on the class with the assembly level hooks
public abstract class SeleniumTest
{
// it used to be [AssemblyInitialize]
[BeforeTestRun]
public static void AssemblyInitialize(/* note there is no TestContext parameter anymore */)
{
// ...
}
// it used to be [AssemblyCleanup]
[AfterTestRun]
public static void AssemblyCleanup()
{
// ...
}
}

Create a Base TagHelper with no TargetElement

I'm creating a library of MVC6 TagHelpers for a large project.
I find myself writing certain functionality in these TagHelpers again and again.
I'd like to make a base TagHelper that all the others inherit from to remove all the duplicated code.
The issue is this - suppose I create a base TagHelper as below:
public class BaseTagHelper : TagHelper
{
public override void Process(TagHelperContext context, TagHelperOutput output)
{
//Some implementation...
}
}
Now, when I go to write a view, I will have intellisense suggesting the taghelper <base>.
Is there any way I can tell intellisense that this isn't a TagHelper I actually want to use, just a base class containing implementation common to other TagHelpers I've created?
Create it as an abstract class, see some examples in the official MVC Core repo like CacheTagHelperBase
public abstract class BaseTagHelper : TagHelper
{
public override void Process(TagHelperContext context, TagHelperOutput output)
{
//Some base implementation...
}
}

Mvvmcross Testing different view models fails when running together

I've come across an interesting error. I have two test files for my xamarin mobile application, both testing view models:
public class TestFirstViewModel : MvxIoCSupportingTest
{
public void AdditionalSetup() {
//Register services and dependencies here.
}
[Fact]
public TestMethod1() {
// Successful test code here.
}
}
That's in one file. In another file, I have:
public class TestSecondViewModel : MvxIoCSupportingTest
{
public void AdditionalSetup() {
//Register services and dependencies here, slightly different from first
}
[Fact]
public TestMethod2() {
// Successful test code here.
}
}
When I run these files individually (I'm using xunit), they work just fine. However, when I run them together, I get the following error on one of the test cases:
Result Message: Cirrious.CrossCore.Exceptions.MvxException : You cannot create more than one instance of MvxSingleton
Result StackTrace:
at Cirrious.CrossCore.Core.MvxSingleton`1..ctor()
at Cirrious.CrossCore.IoC.MvxSimpleIoCContainer..ctor(IMvxIocOptions options)
at Cirrious.CrossCore.IoC.MvxSimpleIoCContainer.Initialize(IMvxIocOptions options)
at Cirrious.MvvmCross.Test.Core.MvxIoCSupportingTest.ClearAll()
at Cirrious.MvvmCross.Test.Core.MvxIoCSupportingTest.Setup()
at Project.Test.TestFirstViewModel.TestMethod1() in ...
Can anyone tell me what's going on here?
The issue stems from the parallelization of XUnit without the option to do proper tear-down. You could diable parallelization in the AssemblyIndo.cs file in you test project by adding:
[assembly: CollectionBehavior(DisableTestParallelization = true)]
I ended up solving this question by changing testing frameworks. I had different ioc singleton initializations, because, well, they're different test cases and needed different inputs/mocks. Instead of using Xunit, I resorted to Nunit where their cache clearing was much more defined: Xunit doesn't exactly believe in setup and tear-down, so it made a test environment like this more difficult.
I fixed the issue by using the collection attribute.
[Collection("ViewModels")]
class ViewModelATest : BaseViewModelTest {
...
}
[Collection("ViewModels")]
class ViewModelBTest : BaseViewModelTest {
...
}
The base view model test class has the mock dispatcher and performs the singleton registrations in the additional setup method.
Each of my tests calls ClearAll() at the beginning.
I hade some success with setup things in a constructor and add this check:
public PaymentRepositoryTests()
{
if (MvxSingletonCache.Instance == null)
{
Setup();
}
//other registerings.
}`
Also I did implement the IDisposable Interface
public void Dispose()
{
ClearAll();
}
But tbh not sure how much impact that had..
It works ok with xunit
Copy MvxIocSupportingTest and Mvxtest in your xunit PCL project.
Modify MvxTest to remove the attributes and use a simple contructor:
public class MvxTest : MvxIoCSupportingTest
{
protected MockMvxViewDispatcher MockDispatcher { get; private set; }
public MvxTest()
{
Setup();
}
...
And in each of you test, derive from IClassFixture
public class TestRadiosApi : IClassFixture<MvxTest>
{
[Fact]
public async Task TestToken()
{
...
xunit will create the MvxTest class only once for all tests.

Access TestContext in SpecFlow Step Binding class

Is it possible to access the MSTest TestContext from within a SpecFlow (1.7.1) step binding class?
In the generated code of a feature file there is a method FeatureSetup which takes the TestContext as an argument but apparently doesn't do anything with it.
I found a way to pass parameters to TestContext and then access them from SpecFlow.
By adding a [TestClass] which has a TestContext property and marking its AssemblyInit() method as [AssemblyInitialize] so it gets initialized early before runnig the tests and MSTest will be able to populate the TestContext.
{
[TestClass]
public class InitializeTestContext
{
public static TestContext Context { get; private set; }
[AssemblyInitialize]
public static void AssemblyInit(TestContext context)
{
Context = context;
}
}
}
And then can access it from my BaseSteps class:
{
public abstract class BaseSteps : TechTalk.SpecFlow.Steps
{
public string GetTestEnvironment()
{
TestContext testContext = InitializeTestContext.Context;
string testEnvironment = testContext.Properties["Environment"].ToString();
return testEnvironment;
}
}
}
Gáspár Nagy answered on SpecFlow google group: https://groups.google.com/group/specflow/browse_thread/thread/5b038e3e283fdbfe#
By default not. We have a test-provider independent ScenarioContext.Current that can be used for similar purposes.
Further to Valentin's answer. Here is an example of a test generator that will add in the test context. Its from the same Google group.
Gáspár Nagy said it may be added to the provider that ships in specflow.
So to answer the OP's question, yes it is possible.

Resources