Re: Find some consensus


2020-07-20 11:53 skrev Andrew Crosland:
- I am a believer in testing and test-cases - my career has convinced me of the benefits. I strongly support the goal of resolving the "unstable" testcases, and would help if I had a clue of the common failure-modes and their common solutions, at least for those parts of the code where I feel that I have some strong level of experience.
This is another area where expertise counts. I am keen to write good
test cases but suffer from the "I'll do it later when the code is
working" attitude. Having CI mandatory tests for every class is a good
thing. I will often cut, paste and adapt code from a similar test
class. In doing so I do sometimes feel others are sometimes as guilty
as me in writing only the most basic test class to call the
constructor and not revisiting later. In my case I think I need a
deeper understanding of unit testing and how to write good test cases,
e.g. knowing what facilities for available running/monitoring tests
and loggong results. Is there a good primer for Junit (is that what we
use now) and how to monitor test results and log the them?
Some thoughts about testing:

I start with writing tests for small simple methods. It's often easier to write tests for simple methods than complex ones, it gives me experience of writing tests, and by making the simple parts less fragile, the more complex parts gets less fragile as a result. (If the bricks fall apart, the house will fall apart).

I find it very useful to look at the coverage. For example, I run:

mvn test -Dtest="jmri.jmrit.beantable.LogixNGTableActionTest,jmri.jmrit.logixng.**.*Test"

to test my code and then run:

ant coveragereport

to generate the coverage report. That creates the folder "coveragereport" with one sub folder for each package in JMRI. For example, the file "coveragereport/jmri/Conditional.html" shows the coverage of the class jmri.Conditional.

The coverage report lets me see which parts of the code that already have tests and which parts that don't.

If the code has some constant values that are important, for example:

public final static int TURNOUT_THROWN = 2;
public final static int TURNOUT_CLOSED = 4;

I write tests that tests the values of these to prevent that these values are changed by misstake. See the class jmri.ConditionalTest as an example of that. I do that for constants that must stay constant over time, for example if the value is stored to XML files or used in communication with a microcontroller. This has the effect that if somebode really wants to change these constants, they have to change the constant in two places and therefore are forced to think a second time of what they are doing.

And last but not least:
Every single test counts! I did some work on writing coverage on Logix, mostly testing small simple methods in the Logix classes. That work got far from complete, but at least the Logix code is less fragile now than it was before.


Join to automatically receive all group messages.