I am writing test cases for my DataAccessRepository ( using entity framework) class. This class takes two argument in constructor. 1) connection object 2) Automapper object
Now, I am using collectionFixture in xunit to pass DatabaseFixture in my test class but I need to pass AutoMapper Fixture as well to the same test class. I tried adding two collection, one after another but it is not valid. Can someone please throw some light on how to use more than one FixtureCollection on a test class in xunit.
My Unit test class looks as follows and it is throwing error as I can not use two CollectionFixture attribute on the class,
`
[Collection(Traits.DatabaseFixtureCollection)]
[Collection(Traits.AutomapperFixtureCollection)]
public class MyAssessmentRepositoryTests
{
private readonly IMyAssessmentsRepository _Repo;
public MyAssessmentRepositoryTests(DatabaseFixture dbFixture,AutomapperFixture amFixture)
{
this._Repo = new MyAssessmentRepository(dbFixture.IcmDbContext,amFixture.Mapper);
}
}`
xUnit.net creates a new instance of the test class for every test that is run, so any code which is placed into the constructor of the test class will be run for every single test.
XUnit by default run all test tests in parallel which are sitting in separate class files. This makes it easy to run our test in parallel without us doing any special configuration.
Hence, there are no [SetUp] and [TearDown] attributes in xUnit.net. Alternatively, xUnit developers use the constructor for initiazilation and IDisposable for the de-initialization of a test class.
Fact vs Theory Tests The primary difference between fact and theory tests in xUnit is whether the test has any parameters. Theory tests take multiple different inputs and hold true for a particular set of data, whereas a Fact is always true, and tests invariant conditions.
See https://xunit.net/docs/shared-context
A single test class can only be in one Test Collection (which is why there is such a constraint on the Attribute).
The solution is to declare a single 'virtual' Test Collection, which declares the two fixtures that a test in such a collection should have controlled access to via ICollectionFixture<X>
s.
When this is in place, the Test Class ctor is furnished with any of the Fixture instances as needed.
(You can also use an IClassFixture
at the Test Class level to declare stuff outside of the Collection [but such Fixtures will be spun up/down] per execution of tests in that Test Class as opposed to ones at Test Collection level which will be spun up/down just the once for the entire run and handed to all Test Classes in the collection as they take their turn to access the Collection Fixture])
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With