-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix for issue #1065 NUnit to destroy ActorSystem after each test run inline with XUnit #1092
Fix for issue #1065 NUnit to destroy ActorSystem after each test run inline with XUnit #1092
Conversation
Code-bombing people is a much better alternative than introducing breaking changes to the API, so I approve :) |
The TestKit API is stable as of 1.0. There's no possibility of changing it. NUnit must work with it. |
@garethbudden this looks great - just finished my review. Could you have |
fc4e5a7
to
d7b1c8f
Compare
I've added the code 💣, and made the TearDown method call I haven't made the TearDown method call |
Ty sir! |
…fter-each-test-run Fix for issue #1065 NUnit to destroy ActorSystem after each test run inline with XUnit
@Aaronontheweb -- nunit 3.13 adds
|
@mchandschuh we might need to patch Akka.NET first in order to fix this. |
I've made changes as outlined in #1065 to allow NUnit's TestKit to work in the same way as xunit.
Problems
Providing an ActorSystem in the constructor will fail
Unlike xunit (and I think mstest), NUnit does not create a new instance of the test class for each test run. If the user provides an
ActorSystem
in the constructor, all tests will attempt to use the same system, however after each test the system is destroyed. One possible fix would be to take aFunc<ActorSystem>
instead, however that would introduce a breaking change to the API for all TestKit implementations and I wasn't sure how you'd feel about that. Another option is simply to throw aNotSupportedException
in the NUnit TestKit if the user provides an instance ofActorSystem
.Redundant methods
The NUnit TestKit has
AfterAll(), Dispose(), and Dispose(bool disposing)
methods, however these are redundant as the class now uses a TearDown attribute to clean up. Removing these methods makes sense but again introduces a breaking change. Would this be a problem?