Sunday, 24 February 2013

Using Delphi code coverage

I couldn't find a good self-explanatory example for the usage of Delphi-code-coverage tool so here you will find a simple example from top to bottom. The idea is really simple; I have a set of units which I want to know whether they are covered by my unit tests or not. Even though there is a lot of information about the project, I couldn't find a really good example explaining all the details about How to properly set up the project, folders, flags, etc. I have used the Delphi-code-coverage-wizard which is great to generate the initial structure (batch file + list of paths + units) but I went manual from there as I couldn't get any output.
I must say that both projects are really good and that's why I'm giving them an opportunity as I want to test the coverage of my projects under Delphi XE.
First step is to correctly identify where your source code is and your unit tests are. This step is really important as to correctly set-up the code coverage project. All my testing code is under my repository and available here: Delphi-repositoty. For this example I'm using a very simple example where I have a unique unit test which tries to cover two units (thundax.AbstractFactory.pas and thundax.Prototype.pas).

My unit test project is called thundax.DesignPatternsTest.exe which has 2 tests:
Now I want to know if those two unit tests cover my previously defined units (thundax.AbstractFactory.pas and thundax.Prototype.pas).

Download Delphi-Code-Coverage and leave it under your bin\ folder or where your test.exe application is (in my case thundax.DesignPatternsTest.exe).
Create two text files called dcov_paths.lst and dcov_units.lst. You can use Delphi-code-coverage-wizard to set up the initial structure, but I would rather go manual as I have more control of the execution.

- The first file (dcov_paths.lst) will contain the path to your source code:

- The second file (dcov_units.lst) will contain the list of unit tests you want to check whether they cover your code or not.

Your projects needs to have debug information generating a detailed Map file:

Now we can create a small batch file (dcov_execute.bat) or run the following command from the command line tool:

This is the configuration that works for me, where:
  • -e identifies the executable to run (in this case the Unit test framework).
  • -m identifies the map file (the map file contains all the debugging symbols).
  • -ife include file extension (if you are using generics.collections use this option).
  • -uf list of your units (source code, not your unit tests code).
  • -spf list of source directories.
  • -od Output directory (".\" gets  the current).
  • -lt generates log file. (Delphi-Code-Coverage-Debug.txt).
  • -html Html output
  • -xml Xml output
  • -emma EMMA output
  • -meta Generate separate meta and coverage files when generating emma output - 'coverage.em' and 'coverage.ec' will be generated for meta data and coverage data. (Needs -emma as well). These are the important files to run EMMA.
Once the line has been run, you should get the correct output files:
  • CodeCoverage_summary.html (Html output)
  • CodeCoverage_summary.xml (xml output)
  • coverage.es (EMMA output)
  • coverage.em (EMMA output)
  • coverage.ec (EMMA output)
  • Delphi-Code-Coverage-Debug.txt 
  • thundax.AbstractFactory(thundax.AbstractFactory.pas).html (Your report)
  • thundax.Prototype(thundax.Prototype.pas).html (Your report)

If you open the summary you will see the total of lines and %age covered by your test:

And you can inspect the files by doing click on the links:
As you can see, one of the units is only 69% covered. Once we inspect the file we can see that there are lines (highlighted in blue) which are not covered by my unit tests and the green ones which are.

If you want to use EMMA, is as easy as this (once the code coverage tool has outputted the .ec and .em files):


Emma component will generate a coverage folder with the following html file:

The entire example can be found in my Delphi repository.

I hope you find this useful and start using it.
Jordi

Sunday, 3 February 2013

Macro actions (mouse and keyboard) with Delphi

I know this could be an old topic, but I find really useful to know how to send the key strokes or how to simulate the mouse click using our favourite language: Delphi. It's for this, that I have create a small open source project where you can find one of my latest tools "thundax macro actions". In here you will be able to add a sequence of actions e.g move the mouse to a particular position, perform right click or left click and type any kind of message or just press a special key like CONTROL or F1, etc. to automate repetitive tasks or actions that you usually perform and that you need to do as quick as possible. As I always automate everything, it was a really nice idea to come up with this solution and it is quite pleasant to see it working for you. All the source code is available and it is free for anybody to inspect, comment and give suggestions to improve this little tool. I have used the tool to perform a series of operations without me interacting and it saved me loads of time.

Imagine that you need to go through a text where you need to add an extra character or something which would be really tedious to perform manually. With this stand-alone tool, you will be able to perform the same operation with just defining the list of actions to execute and off you go.

The code is really easy to understand and the way to send the key strokes or to perform the left/right click of the mouse are really easy to do. You'll find hundreds of examples on the net:

Here is the tool:

Download it from the following link:
There are still loads of things to do to complete the tool, but at least there is a working solution which can now be used.

Related links:

Monday, 14 January 2013

Using Quick Sequence Diagram Editor (sdedit) in your Delphi applications

My first article of the year is about Quick Sequence Diagram Editor (sdedit), a tool for creating UML sequence diagrams from textual descriptions of objects and messages that follow a really easy syntax. The ones who follow my blog will realise that I love logging details for my applications and with this component you will be able to create a nice sequence diagram from any of your real business scenarios. I have been dealing lately with loads of different multi-threaded applications and it was when doing some of my homework for Uni when I found this marvellous gem.
I have written a small and quite straight-forward wrapper in Delphi which will help you to generate the ".sdx" file and run the converter calling the library via java command. All the source code and examples can be found in my personal repository on Google code: thundax-delphi-personal-repository where I keep all my tests and things I want to try out.
With few easy callings, you can instantiate the TUML class and use "start" and "call" methods to generate things like this:

More complex example:


It is really useful when doing reports or to display any of your business scenarios in a nice way. One of my tasks was to create a small application which would send messages across different instances in a supercomputer and this is the best way I found to really present what was going on in there. You can generate huge diagrams and sdedit will cope with it.

Here is the piece of code for the wrapper:
And this is a more realistic approach, where we can have for example 3 different threads which will perform different operations at a different times. All of them are asynchronous and they use the TUML class to show how long every thread took to finish its processing.

Example:

A more realistic approach (Output):

I hope you find this article interesting enough to catch you attention as it is always good when finding tools like this an that are easy enough to integrate with any language and with great results.

Don't forget to leave your comment.

Jordi Corbilla

Thursday, 13 December 2012

Capturing console output with Delphi 2010/XE (revised)

Following my previous post (Capturing console output with Delphi 2010/XE) and with all the great comments received on it, I have decided to publish the new solution provided by Lübbe Onken which solves the hanging issue when capturing the output for different kind of commands like ping, netstat, etc. The problem occurs on the last ReadFile which this solution will fix.
Here I'm summarizing Lübbe Onken comments on this issue:
"The current implementation assumes that if the external process is not finished yet, there must be something available to be read from the read pipe. This is not necessarily the case. If we use PeekNamedPipe to check for available data before entering the internal repeat loop, everything is fine.
I also put the CloseHandle into try ... finally and moved Application.ProcessMessages behind the internal read loop, because IMHO the screen update is better handled after processing the callback than before. But this is just cosmetic."

Here you can find the source code:


usage:

I want to say thanks to everyone who spend time looking at this issue and for making the community work and grow.
Jordi

Monday, 6 August 2012

Rpi and GPIO testing

In this article I'm showing my progress with the RPi using the GPIO. There are lots of interesting articles where people is doing the same, but you won't get the same feeling that I have until you test it by yourself. This application processor board is extremely delicate and you need the get used to its I/O, typical voltage values (3.3V), maximum current (8-11mA), etc. Few basic things that will help you not to burn the RPi (connect resistors after every LED, etc). My example is quite simple but with academical purposes and I'm sure it will inspire others. I'm using the slice of a pi extension board where you can easily get the connectors for GP0-GP7 outputs and lit some LED's programmatically.

Material (apart from your RPi):


First thing is to correctly identify the GP Inputs/Outputs from the Slice of Pi (GP0 to GP7 pins). Here are my findings and the correct pin numeration:
GPIO     Slice of Pi
Pin 11   GP0
Pin 12   GP1
Pin 13   GP2
Pin 15   GP3
Pin 16   GP4
Pin 18   GP5
Pin 22   GP6
Pin 07   GP7

As you can see, they are not in order, so you need to spend time looking for the right pins. I still need to identify all the other pins but I'll get to it.

The following code is just lighting up 8 LED's using 8 GPIO pins as outputs. Each pin is connected to a 220 ohm resistance plus a red LED and all terminations to GND.

Source code:


Example with two LED's:

Here is the video displaying the results:


Keep playing!.