Tuesday 30 August 2011

Visualising Data

With the development of pathvIEw, we wanted to provide a graphical display of how complete the testing was for each module. To do this, we developed a new function in IETeGUI to provide a percentage complete indicator to display in a listbox cell, like this:


This got us thinking about other ways of visualising data to make it easy to glance at a table of data and see the most important bits. We therefore created two additional bar chart styles which are illustrated below. The first style is just a single bar and is used to illustrate the number of statements - the longer the bar, the more statements there are.

The second style is similar to the first, except that the colour is based on a medium and high threshold. We have used this for the complexity column, with green showing low complexity values, amber for medium complexity and red for high complexity.



The nice part about using IETeGUI is that the above is handled without the need for any additional OCX controls and is displayed in a standard Gen listbox.

Friday 26 August 2011

Cyclomatic Complexity and CA Gen

As part of the development of pathvIEw, we have introduced a new complexity  metric which is calculated for each action block and procedure step.

We conducted some research into the usefulness of the metric and this shows some interesting results into the use of complexity counts for predicting error rates in code and hence for its use in prioritising testing efforts.

See the research document here: Cyclomatic Complexity and CA Gen.




Thursday 25 August 2011

Detecting Redundant Code

We recently launched pathvIEw - a new Code Coverage testing tool for Gen, and since using a product yourself is the best way of gathering ideas for enhancements and improvements (as well as testing it of course), we have been using pathvIEw as part of our testing to ensure that we have covered all of the paths through the logic.

When you find that some branch of the code has not been executed during the testing, this could be because your testing has not been thorough, but it could also mean that you cannot get to these statements, i.e. it is code that can never be executed and hence can be removed.

Whilst testing some new functions in pathvIEw recently, there was a block of code that had never been executed, and when I looked at the path through the logic to this code, it became apparent that it was never going to be executed, and hence could be removed.