>From my personal experience: * Use NUnit, don't run tests in parallel (default) * Use TcpDiscoveryStaticIpFinder - avoid default Multicast to avoid forming unexpected clusters * Set IgniteConfiguration.Localhost to "127.0.0.1" to avoid binding on external interfaces * Start at least two nodes to simulate distributed environment (set IgniteInstanceName for this) * Reduce number of Ignite starts/stops for perf reasons: instead, create a new cache(s) for every test to isolate test data. * Optionally use something like TestContextLogger [1]
[1] https://github.com/apache/ignite/blob/master/modules/platforms/dotnet/Apache.Ignite.Core.Tests/TestUtils.cs#L673 On Thu, Apr 1, 2021 at 5:20 PM Pavel Tupitsyn <[email protected]> wrote: > 1. Yes, you can start any number of nodes in the same process for unit > testing > - that is what we do in the Ignite tests themselves > > 2. You can isolate clusters by using StaticIpFinder and CommunicationSpi > with different ports > new IgniteConfiguration > { > DiscoverySpi = new TcpDiscoverySpi > { > IpFinder = new TcpDiscoveryStaticIpFinder > { > Endpoints = new[] { "127.0.0.1:55000" } // Change this port > } > }, > CommunicationSpi = new TcpCommunicationSpi > { > LocalPort = 55000, // And this port > LocalPortRange = 10 > }, > } > }; > > However, NUnit does not run unit tests in parallel by default, so you may > not need to deal with this (we don't). > > 3. Create a temp dir and set IgniteConfiguration.WorkDirectory, remove in > TearDown > > > As for Unit tests vs Functional tests vs Integration tests - this debate > is endless. > Integration tests that use actual DB provide more value, because you > actually > test that the whole system works. But they are slower and more > resource-hungry. > > You can mock/fake Ignite - all APIs are interfaces (IIgnite, ICache, etc). > > On Thu, Apr 1, 2021 at 4:59 PM Kathryn Hogg <[email protected]> wrote: > >> What is the best recommendations for automated tests of applications that >> use Ignite? On one hand you have Unit test purists that insist that you >> should be mocking data that is coming from Ignite. On the other hand, you >> have more practical people that say if you do that, you can't actually unit >> test your code that uses Ignite. >> >> >> >> If it matters, we're using Ignite.Net fat client and NUnit as our unit >> testing framework. I have verified that a standalone ignite works in a >> unit test. But I imagine we need to ensure things like: >> >> >> >> · prevent concurrently running unit tests from forming a cluster >> >> · ensure each unit test has its own work directory and this is >> cleared out before running each test. >> >> >> >> >> >> -- >> >> Kathryn Hogg >> >> Principal Technology Architect >> >> >> >
