As an ardent promoter of Mutation Testing, I sometimes get comments that it’s too slow to be of real use. This is always very funny as it also applies to Integration Testing, or GUI. Yet, this argument is only used againt Mutation Testing, though it cost nothing to setup, as opposed to the former. This will be the subject of another post. In this one, I will provide proposals on how to speed up mutation testing, or more precisely PIT, the Java Mutation Testing reference. Setting the bar
Working on a legacy project those last weeks gave me plenty of material to write about tests, Mockito and PowerMock. Last week, I wrote about abusing PowerMock. However, this doesn't mean that you should never use PowerMock; only that if its usage is commonplace, it's a code smell. In this article, I'd like to show an example how one can refactor legacy code to a more testable design with the temporary help of PowerMock. Let's check how we can do that using the following code as an example.
I’ve always been an ardent proponent of internal quality in software, because in my various experiences, I’ve had more than my share of crappy codebases to maintain. I believe that quality tools can increase the internal quality of the code, thus decreasing maintenance costs in the long run. However, I don’t think that such tools are the only way to achieve that - I’m also a firm believer in code reviews. Regarding quality tools, I started with Checkstyle, then with PMD,
Last week, I had a heated but interesting Twitter debate about Code Coverage with my long-time friend (and sometimes squash partner) Freddy Mallet. The essence of my point is the following: the Code Coverage metric that most quality-conscious software engineers cherish doesn’t guarantee anything. Thus, achieving 80% (or 100%) Code Coverage and bragging about it is just as useful as blowing in the wind. For sure, it’s quite hard to have a fact-based debate over Twitter, as 140 chars
This week, I've lived again an experience from a few years ago, but in the opposite seat. As a software architect/team leader/technical lead (select the term you're more comfortable with), I was doing code reviews on an project we were working on and I stumbled upon a code throwing a NullPointerException: that was a big coding mistake. So I gently pointed to the developer that it was a bad idea and that I'd like him to throw an IllegalArgumentException instead, which exactly the exception type m
Last week, Simon Brandhof and Freddy Mallet of Sonar team and me were discussing Vaadin uses. At the end of our meeting, and although Vaadin finally did not fit their particular needs regarding Sonar, the talk disgressed toward quality. As regular Sonar users know, the former includes a very interesting plugin aptly named Technical Debt plugin. As a reminder: Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite
Sonar is a free OpenSource product that provides you with a general dashboard displaying information about the codebase of each configured project, such as: Number of failed tests,% of code coverage,% of rules compliance (more later),% of duplicated lines,and much more. Then you get an additional graphical information showing: a square for the size of your project’s codebase relative to the entire codebase’s size,a color (from red to green) for the % of rules compliance. Yet, w