Unit test best practices

[Kathryn Hogg <Ka...@oati.net>]

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

Re: Unit test best practices

[Pavel Tupitsyn <pt...@apache.org>]

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 <pt...@apache.org> 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 <Ka...@oati.net> 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
>>
>>
>>
>

Re: Unit test best practices

[Pavel Tupitsyn <pt...@apache.org>]

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 <Ka...@oati.net> 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
>
>
>