Today is Friday, 3rd July 2020

Archive for the ‘Test Driven Development’ Category

Continuous Integration: Technical Practices

In software engineering, continuous integration (CI) implements continuous processes of applying quality control — small pieces of effort, applied frequently. Continuous integration aims to improve the quality of software, and to reduce the time taken to deliver it, by replacing the traditional practice of applying quality control after completing all development.

– Source: Wikipedia

Build Software At Every Change

  • Automate builds
  • Separate build scripts from IDE
  • Centralize software assets
  • Use consistent directory structure
  • Use a dedicated build machine
  • Use a CI server
  • Run integration builds
  • Stage builds

Continuous Database Integration

  • Automate database integration
  • Use a local database sandbox
  • Use version control for db assets
  • Give developers access to modify db
  • Make DBA part of dev team

Continuous Inspection

  • Reduce code complexity
  • Perform design reviews continuously
  • Maintain code standards with code audits
  • Reduce duplicate code
  • Assess code coverage

Continuous Testing

  • Automate tests: unit, component, functional
  • Run faster tests first
  • Write test for defects
  • Make component tests repeatable

Continuous Deployment

  • Release working software, any time
  • Produce a clean environment
  • Label each build
  • Run all tests
  • Create feedback reports
  • Possess capability to roll back release

Book Recommendation

If you are interested in continuous integration, then I would highly recommend the book.

Code Coverage in Java

Code coverage provides information on how much of your application is executed. It is a good way to find dead code in your project (ie code that is never executed). I have been using code coverage for my unit testing. The code coverage will tell me how much of my application is covered by the unit tests. You can find more general information on code coverage here.

A popular code coverage tool is Emma. It is an open-source code project that has been around for a while. The website has documentation on how to run Emma from your Ant file.

I also found two really great sites to get started with code coverage in your favorite IDE.

Finally just for kicks, Albert Savoia (formerly of Sun) has a great article on code coverage. The article is written in an offbeat style, using a martial arts master / apprentice dialogue. Very funny read 🙂

Ok, that’s it from me. Make sure your code is covered. Enjoy.

Creating JUnit Reports with Ant

Hopefully, you are using JUnit on your project to unit test your code. If you’re new to JUnit then read this primer. JUnit provides an Ant task that can great generate HTML test reports. These reports are useful to show to your management team. They are also useful if you are running automated builds and you want to review the results of the tests at a later time.

If you’re using Maven then this feature is already available with the “mvn site” command.

Here’s a screen shot of sample report.

The report shows a list of all test cases for each class.

Developing the Ant File

Below is an Ant file for generating the JUnit reports.

As you can see, this is Ant file follows the usual format of Ant files. At the beginning of the file, we set the appropriate directories for our Java source code and JUnit tests. We also have the standard javac task for compiling the code.

Lines 39 – 53, introduces the junit Ant task. This task will run the JUnit tests and produce the test results. The test results are placed in a plain text file and an XML file.

Line 39 is the beginning of the task and we tell the system to stop executing if we encounter an error/exception or a test failure.

Lines 40-41 describe the type of output files to generate. In this case, the task will generate a plain text file. It also generates an XML file that we can use later to generate HTML (via XSL).

Lines 42-47 define the JUnit test cases to include in this report. For our example, we will include all unit tests that end with “Test” (* and “All”, (Test*

The next section handles the generation of the HTML pages for the test results.

Lines 58-63 make use of the junitreport task. This task reads the test output files from the previous junit task. The output files have the format of “TEST-*.xml”. The generated reports are stored in the directory “”. You can open this directory and open the index.html.

Test It Out

  1. Make sure you have Ant installed, if not then you can download it from here
  2. Download the source code for this blog article
  3. Extract the files to a directory on your file system
  4. Open a MS-DOS window or terminal window
  5. Move to the directory where you extracted the files
  6. Type:  ant report
  7. Using a web browser, open the file: build/report/html/index.html

You can now see the results of the unit test. Enjoy.

Good luck!

Book Recommendations