Комментарии:
Thanks so much for sharing!
ОтветитьFinally, I ended up with own console app and reflection... NUnit can be frustrating,if you need to test appdomains
ОтветитьHi Nick any idea how to use this with specflow and xunit get this error "Duplicate 'Xunit.TestFramework' attribute"
ОтветитьThe fact is XUnit parallelization is on by default, but It is class-dependant as you showed, or feature-based in case of working with SpecFlow, it will treat each feature file as a collection, even with Meziantou
ОтветитьYou should show us Playwright for dotnet running in parallel with NUnit. I have an example repo called nullptrerror/DotNetE2EStarterKit that you can use as a starting point.
ОтветитьAlternatively you use the superior test framework NUnit.
It supports multiple parallelizable scope definitions with zero additional setup.
I think it's time for another Blazor video with the upcoming release of .NET 8. It appears to finally be a platform that we can take seriously as an alternative to React and friends.
Also, honest opinion, the videos that involved correcting LinkedIn posts are not particularly interesting, at least not to me.
Hey Nick, I'm doing your unit testing course but I have a wierd problem in Visual Studio. It seems to double up all the tests in the test explorer and runs them all twice. Also the "double up" that I have skipped seems to ignore the Skip ="" and still runs the test (the first instance of the test works as expected), resulting in a failed test. I just can't figure out why it is doing this. Any ideas? have you seen this before?
ОтветитьDoesn’t work with IAssemblyFixture. Ended up needing to write custom xUnit runner
ОтветитьThanks a lot. I would like to see a video on the same subject, but with multiple test projects.
ОтветитьLooks good Nick thanks. You didn't really go into it but just hinted at the fact there would be ways to achieve parallelism and still benefiting from class/collection fixtures. It would be cool to see a "part 2" on that
ОтветитьI have always used NUnit where parallel execution is built-in. I haven't used xUnit much, but it is strange that you need to install external libraries to achieve this. However, xUnit probably gets the job done as well.
I write all tests to support parallel execution if applicable. This may work for unit tests easily, but for integration and UI tests it gets much more complicated.
Seems like a pretty big downside vs NUnit which has very easy ways to manage parallelism
ОтветитьMeziantou.Xunit
ОтветитьFirst I read in the title: The fastest way to ruin your tests in .NET 😂
ОтветитьIs it possible to set it up so that you have to enable parallelisation per class rather than disable it?
ОтветитьNot a fan of "magical" solutions...
Would rather like to understand what is that Nuget package doing.
Interesting fact that by default in one test class tests are executed sequentially, but the order of tests is not garanteed. Basically, order is random.
ОтветитьI solve the state issue by having an initialize method run that resets all state, I think I do it with the test initialize attribute in nunit so I’m sure their could be something similar in XUnit. I used to have tons of state issues and now I don’t, cheers
ОтветитьI don't see how it can significantly increase the performance in real applications. If you have 100 test classes 5 methods each you will not have enough threads to execute all of the methods at the same time. So if a test runs every class testcase subsequently and in parallel you have other 99 classes which are go to thread pool to execute in parallel, the performance is going to be almost the same
ОтветитьReally good to know that, learned new stuff!
We can only achieve this parallelization in the same collection using the Package? Wondering why xunit didn't added this be default.