Easy way of counting effective lines of code from the console

When looking for nifty one-liners on the web that counts the number of non-blank or non commented lines in my code I ran in to CLOC. If you have a thing for working in the console, CLOC is a really nice tool for counting lines of code in a set of folders or archives. If Sonar is available and configured it is excellent but sometimes there might simply be easier to run things quickly and locally from a console, pick your favourite one-liner, tweak the sed OR just use CLOC.

Could not be easier
Download and put the executable in the path and run for a given folder,

$ cloc <the folder with my code/archive-file>

and you will get the output

http://cloc.sourceforge.net v 1.56  T=43.0 s (35.2 files/s, 7550.3 lines/s)
Language                     files          blank        comment           code
XML                            680          36091              5         149257
HTML                           699          30773              5          79958
Java                           106           3130           4904          16395
Javascript                      18            430            190           2384
CSS                              6            184             47            862
Python                           1              6              5             30
Bourne Shell                     2              2              0              4
DOS Batch                        2              0              0              3
SUM:                          1514          70616           5156         248893

There are many, many flags (http://cloc.sourceforge.net/#Options) that can be used for filtering and tweaking the output, so from now on this is one of the must have tools on my machine.

Using JUnit @Category and Maven profiles to get stable test suites

Since it happens over and over again, no matter what project I am in. Keeping the test suites green and passing is a …

The blind eye

The one sneaking little test case that starts failing can prove to be a real killer to all automation approaches. More than once it has shown that as soon as a single test case breaks a test suite things starts to go downhill, fast. Ok, there could be acceptable resons for the test case to be broken, e.g. if there are issues in the system under test or in the test framework that are not bugs.

The usual decision taken is to leave the test case as is for now since we are all aware that it will fail for a while, BAD choice!!! All attention on the failing test suite is moving from slight attention to abandoned, and if other test in the test same test suite starts failing for various reasons it will most likely go by undetected.

What can/should be done here

  • Disable the test case and enable it again when it should be back on track
  • Maintain test suites to allow it to execute and fail but in a another suite/run to keep the MUST always pass test suites all green

The later case is the way to go.

Maven profiles to your rescue

Using Maven profiles it is easy to group your JUnit test classes and test cases in different categories. Usually this is used for grouping tests into slow, fast and browser-less tests a.s.f.. This approach can be stretched even further by using a grouping that reflects the current state of the test case. There does not have to be that many different groupable categories but at least two is needed.

  • Stable
  • Unstable/Maturing

Stable is self explained while Unstable/Maturing covers everything that is NOT always PASSING. It might be test cases that are unstable beacuse of;

  • timing issues
  • tested functionality is still under development (during sprints)
  • there is a low priority bug that will be fixed later
  • unknown issues causing it to sporadically fail
  • waiting to get a STABLE stamp

Use case 1
The last item is an approach that can be used to be really be sure that the stable test suites does not get polluted. Any new test case needs to run a set number of times (e.g. 20) in a test suite and must pass all all times before being stamped as a reliable test case.

Use case 2
When a bug surfaces that causes a test case to fail it might sometimes be the case that it wont be fixed for some time period. Instead of totally disabling or trying to fix the test case that would fail an otherwise stable test suite it shall be moved to an unstable test suite. This is a way to put the test case in a quarantine until the bug has been fixed and on the same tame make sure it still compiles and is executable.

Categorizing tests using JUnit @Category annotation
Use the JUnit @Category annotation in front of your test cases or test classes.

public void aTestCase() {
  // void

// Alternatively an unstable test case

public void anotherTestCase() {
  // void

Splitting test execution using Maven profiles

Configure your Surefire plugin to include and exclude certain test classes as well as determine a set of JUnit @Category groups to be included in the test run. Set up your pom including profiles as examplified below.


The testcase.groups property can be used to define a set of groups (JUnit @Categories) to include when tests using the actual profile.


Test suite pollution – missing term in test glossary

Test suite pollution is when one or more automated test cases deliberately are allowed to fail in a test suite. This usually leads to the executing test suite to be un-attended since errors are expected, a very unfortunate situation during development. New defects surfacing can easily be missed out and the longer the test suite gets ignored recovering it to stable can be cumbersome.

This is just an attemp to clarifying one of the ‘buzz’ terms I preach to my team. Please correct me if you think I am out of line.