Unit Tests

Coordinator
Jul 5, 2012 at 3:27 PM
Edited Jul 5, 2012 at 3:29 PM

To put it mildly, our code coverage is not so good:

If you have, please provide Unit Tests. Either, if you have commit rights, directly to the UnitTests project, otherwise we are thankful for every patchfile.

FObermaier

Coordinator
Jul 5, 2012 at 5:37 PM

It is also very usefull to use dotCover to increase test coverage, if you are a SharpMap developer and contribute to the sources - you can use OSS license (ask Felix by email for it).

Also make sure unit tests have a very limited responsibility, have a very clear structure (construct / act / assert) and do not test many things in a single tests.

Maybe we should also consider use of tests categories to distinguish between:

1. unit tests - no category, statement, path and other simple tests.

2. integration - something which constructs many classes and tests how they work together, accesses web, file system, etc.

This might be required once number of tests and/or time to run all tests increases.

--

Gena

Developer
Jul 6, 2012 at 4:05 AM

When we "fix a bug" that had "unit test" then we just run the "unit test" and do not need to write a new unit test.

Should be distinguished from "bug fix", edit the source code support for new vesions of preferences project or write a new function

Coordinator
Jul 6, 2012 at 5:58 PM

When there is a failing unit test (reproducing some bug) and it gets fixed by fixing a code - of course you don't need a new unit test. Amount of unit tests should be minimalistic. But when we have a source code which is not covered by a unit test (describing expected behaviour of that source code) - then we may have a problem. Tests are written in order to test how the source code is expected to work and are used to test that expected behaviour automatically (see build server).

In general it is a normal style to write test every time you find a bug:

found a bug -> reproduced that bug in a unit test (expecting that the code works in a certain way - but the test fails) -> fixed code

Coordinator
Jul 6, 2012 at 9:25 PM

Some of the tests can be copied from my branch, it has a lot of design changes, but some code used in tests may apply to the SharpMap trunk as well.

I just configured it to build-test everything. Test coverage there is (some performance tests are ignored - marked as Category(WorkInProgress) because of slow build machines):

NetTopologySuite

Class

38% (131/345)

Method

31% (1009/3255)

Statement

28% (4793/17098) - v1.7.1 + small bug fixes

NetTopologySuite.Extensions 72.5% (29/40) 67.9% (395/582) 72.5% (2101/2897) - mainly network + coverages (new stuff)
SharpMap 57% (61/107) 46.1% (654/1418) 40.7% (3127/7686) - rewritten version, quite a lot but many things still named/look same
SharpMap.Extensions 70.6% (12/17) 51.8% (147/284) 63.1% (1074/1703) - quite some overlap with current SharpMap.Extension in trunk
SharpMap.UI 83% (44/53) 37.6% (237/631)

33.6% (1212/3602) - fully new MapControl + MapTools (interaction)