Unit test best practices

classic Classic list List threaded Threaded
3 messages Options
Kathryn Hogg Kathryn Hogg
Reply | Threaded
Open this post in threaded view
|

Unit test best practices

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

 

ptupitsyn ptupitsyn
Reply | Threaded
Open this post in threaded view
|

Re: Unit test best practices

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 <[hidden email]> 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

 

ptupitsyn ptupitsyn
Reply | Threaded
Open this post in threaded view
|

Re: Unit test best practices

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]


On Thu, Apr 1, 2021 at 5:20 PM Pavel Tupitsyn <[hidden email]> 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 <[hidden email]> 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