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
>
>
>
