This article has been written as “basic knowledge” for Junior Java developers to help them tracking their bugs in Java software.
I was the guest of an amazing French IT company Slickteam last week. The subject was to share experience and tricks about Cleancode.
To be or not to be (happy), that’s the question. In this article, I expose some thoughts about what could make a software developer happy in his work. I wrote this article with several targeted audience in mind : Junior developers, Senior Techleads and H&R resources.
This article is part of my web research to prepare the development of a new feature using Amazon S3 Webservices.
An article dealing with Java application and testing frameworks and related libraries. Continue Reading
Today I was preparing a presentation about Software Code quality for a TechTalk on Thursday. I made a search on Internet about Automatic Unit test generator and Data Generators. I will present some tools I have tried. Today, we will speak of Randoop.
Randoom Test Generator
The first tool name is Randoop.. This tool is existing since 2007 and its purpose is to generate automatically unit tests 🙂 Directly from your class definition!
To use it you have two choices:
- You can use your software JAR or classpath directory.
- You can include it in your test compile path (on gradle or maven) and creates a main or unit test.
To explain short the theory, thanks to the Java reflection it’s quite easy to produce automatic tests validating some contracts of your API.
Some examples: –
toString() should never returns null or throws an Exception –
compareTo() methods have a long list of constraints – Reflexivity:
o.equals(o) == true – Symmetry:
o1.equals(o2) == o2.equals(o1) – Transitivity:
o1.equals(o2) && o2.equals(o3) ⇒ o1.equals(o3) – Equals to null:
o.equals(null) == false – It does not throw an exception
Therefore this tool is generating unit tests with JUnit(
TestSuite) for the list of classes you provide.
I have done some tests and you can reach 50-60% of coverage quite easily.
The main drawbacks of the solution are: – The unit tests are drawing a snapshot (precise picture) of your code and its behaviour however some tests are really non-sense and you don’t want to edit them. – They don’t replace handwritten tests since the tool is not understand the different between a String parameter
fullName. He will mostly use dumb strings.
About the technology, it’s not production ready: – I had troubles with the jar and its dependency
plume. – The JAR is a fatjar and coming with dependencies that broke my software.
In conclusion, I will fork the software and try to fix the problems to make it more popular 🙂
In this article, I will present you two new SonarQube plugins that you will never find on SonarQube marketplace (for some good reasons).