You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've been working on a persistence plugin for Akka.NET and when I went to implement the specs, the difference between what (I think) is going on in Akka and what's going on with Akka.NET really threw me. So I thought I'd ask about it. With the Akka TestKit, when there are multiple tests being run in a spec, it looks like the tests are defined in the constructor. For example:
From what I gather, that means the heavy-lifting done by TestKitBase (creating the Actor System, etc.) will happen once, then the tests will get executed. But they'll all run one at a time on that same Actor System or context that was setup. With our tests using xUnit, we define multiple tests using methods and the [Fact] attribute. But because of the way xUnit works, the constructor for the .NET implementation of TestKitBase will get run before each test, thus we're creating/tearing down a fresh Actor System for each test in a spec.
So I have two questions:
Is my description of how this works correct and if so, is it intentional?
Would it be more appropriate for the xUnit implementation to provide TestKit as a shared context as opposed to it being the base class?
It seems like for the recently added NUnit implementation ( 👍 ), TestKit could remain a base class with the [TestFixture] attribute since NUnit doesn't create a fresh instance of a fixture for each test. I'm not saying that the .NET version shouldn't be different, it obviously should and will be. I just wondered if creating a new Actor System every time is expensive and could be avoided while maybe making things easier to port in the future.
The mismatch with what's going on in Akka leads to some interesting/subtle differences in the ported .NET code which was super confusing to me (granted, I can be an idiot). For example, the Akka implementation of JournalSpec relies on PluginSpec which increments an atomic counter before each test so that each test uses a different persistence Id. In our implementation, that atomic counter is an instance variable just like in Akka, but since xUnit creates a new JournalSpec instance for every [Fact], that counter is always 1. Which means that now the tests in JournalSpec could share test data with previous tests in the spec unintentionally unless you explicitly do something to destroy previous data. In my case, I have to drop the Table or Keyspace in Cassandra and recreate it, which makes the tests way slower than they have to be.
The text was updated successfully, but these errors were encountered:
I've been working on a persistence plugin for Akka.NET and when I went to implement the specs, the difference between what (I think) is going on in Akka and what's going on with Akka.NET really threw me. So I thought I'd ask about it. With the Akka TestKit, when there are multiple tests being run in a spec, it looks like the tests are defined in the constructor. For example:
https://github.com/akka/akka/blob/master/akka-persistence-tck/src/main/scala/akka/persistence/journal/JournalSpec.scala#L63
https://github.com/akka/akka/blob/master/akka-actor-tests/src/test/scala/akka/serialization/SerializeSpec.scala#L132
From what I gather, that means the heavy-lifting done by
TestKitBase
(creating the Actor System, etc.) will happen once, then the tests will get executed. But they'll all run one at a time on that same Actor System or context that was setup. With our tests using xUnit, we define multiple tests using methods and the[Fact]
attribute. But because of the way xUnit works, the constructor for the .NET implementation ofTestKitBase
will get run before each test, thus we're creating/tearing down a fresh Actor System for each test in a spec.So I have two questions:
TestKit
as a shared context as opposed to it being the base class?It seems like for the recently added NUnit implementation ( 👍 ),
TestKit
could remain a base class with the[TestFixture]
attribute since NUnit doesn't create a fresh instance of a fixture for each test. I'm not saying that the .NET version shouldn't be different, it obviously should and will be. I just wondered if creating a new Actor System every time is expensive and could be avoided while maybe making things easier to port in the future.The mismatch with what's going on in Akka leads to some interesting/subtle differences in the ported .NET code which was super confusing to me (granted, I can be an idiot). For example, the Akka implementation of
JournalSpec
relies onPluginSpec
which increments an atomic counter before each test so that each test uses a different persistence Id. In our implementation, that atomic counter is an instance variable just like in Akka, but since xUnit creates a newJournalSpec
instance for every[Fact]
, that counter is always1
. Which means that now the tests inJournalSpec
could share test data with previous tests in the spec unintentionally unless you explicitly do something to destroy previous data. In my case, I have to drop the Table or Keyspace in Cassandra and recreate it, which makes the tests way slower than they have to be.The text was updated successfully, but these errors were encountered: