Test case or script naming without version control

Some possibilities for identifying versions and retaining history:

• All names have a numeric version attached to the name, e.g. BestestQTPScript-2.5
• 2 would indicate that there was a major rewrite for whatever reason (i.e. starts at 1)
• 5 would indicate that this is the 6th minor update since the last major update (i.e. starts at 0)
• All names have the creation date attached to the name, e.g. BestestQTPScript-20100206
• yyyymmdd appended to the script name (this format ensures ordering)
• Date is the date of creation/maintenance
• All names have the system version attached to the name, e.g. BestestQTPScript-2.121.45.09
• Direct link between script and system version allowing for execution against the corresponding system version (obvious benefits)
• Script maintenance fairly simple to gather
• Unfortunately its not always simple to get the version number

Refactoring blues

Got stuck into a restructuring of a side line project. Scary stuff when you didn't write the code yourself and have to make modify or kill decisions.

Purpose for this rendering was to simply to dump the garbage and put a little structure into the base. Up to 4 copies of a single file within a project is a great way to introduce errors.

The next refactoring session will have to try deal with:

• Bad files names
• Mucky murky code
• Standardization
  

VBExpress to MonoDevelop

A little look at using Ubuntu for rewriting the QTP Framework into VB.Net.

Launching the project in MonoDevelop spat out a bunch of errors. Figured that this was a simple fix as Google let me know that there was an NUnit add-in for MonoDevelop. Not quite that simple as the versions for the referenced libraries were different. Being a quick look, the resolution to this was to downgrade the version to that offered by the Ubuntu installer. This sorted a few of the errors.

The next bunch all related to a single class file. This file was a barely updated version of the VBScript original. Since nothing was really modified in this file, it was simply trashed.

Added the strict option to the code validation which resulted in a few shouts about missing parameter types. Actual fixes done on the code for these.

Then a run of the unit tests. Quite nice to have the results dished up in the IDE but apparently there is a possible way to get the results in the Express version which I'll try when back in the Window world.

As far as experimentation goes, the only prime issues are those that relate to the direct referencing of the C: drive within the unit test for the file library.  Removing this, should make it possible to remove the platform dependency for completing the development.

Working with jPOS

jPOS is an open source library for handling ISO8583 financial messages. A prime issue I've had is that the environment requires a little customization for handling the implementation of the standard and how to get these changes incorporated into its built in server. Finally I've resolved this by having a separate project for building a JAR that can be included into the lib folder for the jPOS source project which I then run by using the included ant file. The only change then required is the inclusion of the specific configuration files that are then needed within the deploy and cfg folders.

Testing with unit tests

Unit test libraries like JUnit and NUnit provide extensive capability for white box testing. The assertion model essentially translates as a verification of intention. By considering intentions, you should be verifying the design and not proving the code. This is the trap. TDD works when it is implemented with test driven design rather than as tests written to prove code.

The biggest problem I've encountered is maintaining the discipline in the face of impending deadlines. It is easy to develop unit tests when the functionality is unique but when its an artifact of a partially enforced bad design, then the unit test for that particular section seems redundant.

Tester tools

Having been introduced to the tools available to developers has made me more aware of the inadequacy of the tools provided to testers. Subversion, Eclipse, MyLyn, Emma, PMD, and Git to mention a few of the tools that I've recently used. Git isn't quite so far along as the others, but it looks to be a great version control system. Using Eclipse as the development environment provides integration to SVN for version control, MyLyn for task management, Emma for code coverage and PMD for static code review. Test tools seem to be targeting separate solutions. Integration within the testing space is uncommon and exceedingly rare with development.

TDD

Test driven development is a good thing. It can be hard to implement in practice due to deadlines and it not being readily accepted that tests absolutely have to be written.

Case in point. A class was written (as a collaboration of two). The class functioned satisfactorily. With a look of horror, some unit tests were created for this class by a concerned outsider. With some trepidation, the collaborators added more unit tests and eventually every function was covered by the class (thanks to EclEmma) - not every line, but at least every function had a little coverage.

With the dawning of a need to extend the class (4 months on) a new journey dawned. The first challenge... get to 100% coverage. Once that was achieved add the new unit tests, then the code. Horror. The added tests failed. Bugs everywhere. An absolute infestation.

The bugs were not in the code that was used. The code that was used, was adequately covered by the unit tests. The problem was the interface. The exceptions and, obviously, never used paths.

I headed for 100% coverage as I had achieved it in creating another class and had a feeling of confidence in the class overall and not just the paths I knew I was using.

Even when no problems have been found, there are worthwhile solutions.