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.
16th February 2018 | Cloud Computing, DevOps, Digest, Framework, Java Development, Libraries, Opensource, Programming, Software Engineering, Software Technologies, State of the art, Technologies, Testing | 1 Comment
A Dashboard can be a very efficient communication tool for a team, between managers and business units. It enables an organization around a vision to share common goals. It can also be useful to identify weaknesses in processes and adapt your strategy according to them.
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.
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:
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 🙂
23rd December 2017 | Application Lifecycle Management, Cleancode, Code analytics, Code Quality, Code review, DevOps, Programming, Software Factory, Software Quality, SQA, State of the art | 2 Comments