My Testing and Code Analysis Toolbox | Javalobby

My Testing and Code Analysis Toolbox | Javalobby

“Testing Skill Group” at LINEAS

• a group for exchanging knowledge about testing.

Jens Schauder's Personal Toolbox

• JUnit
• don’t take the term ‘unit’ to seriously
• use JUnit to execute all other kinds of tests as well
• Mockito
• has nice DSLish API
• nice to use
• Only drawback is that in some special cases the standard API doesn’t work and one has to use an alternative syntax.
• PowerMock
• You need PowerMock if you want to mock constructors, static or final methods. 
• If you need this, PowerMock gets the job done, but its better not to need it.
• Jenkins
• free
• Not exactly a work of beauty, but it works, 
• is easy to setup and does everything 
• plugins.
• CheckStyle
• other tools
• FindBugs and 
• PMD. 
• You can also use Checkstyle in order to gather simple metrics about your code.
• JDepend
• static code analysis of 
• the dependencies of your code. 
• To write tests against 
• cycles between packages in the code and 
• to limit the dependencies to a certain range. 
• Some limitations in JDepend resulting in dependencies that JDepend misses
• It doesn’t consider classes in annotations or something. 
• DependencyFinder
• way more powerful
• certainly harder to use. 
• A little tool for visualizing dependencies based on DependencyFinder.
• Cobertura/EclEmma
• Emma in the form of EclEmma as an eclipse plugin and 
• Cobertura in Jenkins
• couldn’t get Emma to work on Jenkins instances.
• Sonar
• Tons of metrics from your code and 
• makes them available as a website. 
• numbers.

Testing Techniques - Part 1 - Not Writing Tests | Javalobby

Testing Techniques - Part 1 - Not Writing Tests | Javalobby

• Unbelievably, some people and organisations still do this. They write their code, deploy it to the web server and open a page. If the page opens then they ship the code, if it doesn’t then they fix the code, compile it redeploy it, reload the web browser and retest.
• The original author started out by writing a few tests, but then passed the code on to other inexperienced team members. When the code changed and a test broke, they simply switched off all the tests. 
• You may say that an end to end test like this isn't too bad, BUT to deploy the MDB and to run the test took just over an HOUR: in a working day, that's 8 code changes. Not exactly rapid development!
• My job? To fix the process and the code. The solution? Write tests, run tests and refactor the code. The module went from having zero tests to about 40 unit tests and a few integration tests and it was improved and finally delivered. Done, done.