Thursday, December 31, 2009

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.

Monday, December 21, 2009

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.

Sunday, December 20, 2009

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.

Tuesday, September 1, 2009


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.

Tuesday, July 21, 2009

Roses and thorns

Photograph of a rose.Image via Wikipedia

An article that is attempting to present a warm and fuzzy. Another article with a rather blunt view of things.

Do fuzzy things actually work?

Points 1, 3 and 4 can easily be condensed into a single one - communication. Probably the easiest way to create a bit of loyalty in an employee. It does make me wonder why this is an aspect that is always lacking.

Point 5 promotes gratification, not necessarily a link to the corporate ideal. Maybe there are some people out there who can be bought - but this cheaply?

I would think that point 2 could possibly bring about something. A value system may give the employees and potential employees a personal reason to want to associate themselves with the company.

After wading through the first article the second one comes across as being deplorably honest and pretty amusing.
Reblog this post [with Zemanta]

Wednesday, June 3, 2009

Compare it

Compare is a simple sounding notion. The most commonly neglected requirement is what exactly is to be compared.

The most fundamental question is whether you are comparing files that should be the same or files that are different but contain the same information. The solution obviously are very different. The simplest compare is a file compare but it only works if the files are expected to be identical. Even a single line in a different place can cause some havoc. This brings you into the realm of comparing miscellaneous files.

Miscellaneous file comparisons normally require some level of customization. If the files are tabular, then a simple mapping may meet the needs. However, throw in a degree of irregular ordering and the cute little kitten becomes a temperamental demon.

Tuesday, June 2, 2009

Leisure - WH Davies

What is this life if, full of care,
We have no time to stand and stare.

No time to stand beneath the boughs
And stare as long as sheep or cows.

No time to see, when woods we pass,
Where squirrels hide their nuts in grass.

No time to see, in broad daylight,
Streams full of stars, like skies at night.

No time to turn at Beauty's glance,
And watch her feet, how they can dance.

No time to wait till her mouth can
Enrich that smile her eyes began.

A poor life this if, full of care,
We have no time to stand and stare.

Thursday, May 21, 2009

Useful System Messages

An somewhat not so helpful error message.

A little local admin rights and away with the error.

Wednesday, May 20, 2009

Client site ethics

Eid Mubarak - عید فطر مبارکImage by Hamed Saber via Flickr

Is it within the bounds of ethical behavior to write about the antics of the people at a client site? Is impersonalization sufficient?

Ethics cover a very wide range of behavioral patterns. Generally the normal set of modes is defined by a person's social upbringing. The set is initially imprinted by the parents or caregivers. The next layer is added by the immediate social network in which the parents run as well as the bonds formed in going through schooling. Ethics therefore evolve around the initial values imprinted as a very young age.

All well and theoretical, but not really going towards answering the question. Ultimately though it does bring to the fore that the answer is individual. It is not a question with an answer for all situations and any two people may quite readily disagree on the answer.

Impersonalization does add a level whereby the direct reference to a specific person or corporation is muddled. The indirection however is superficial as a correlation can be made through personal identifications.

From my perspective, the core answer is no - at least in the current situation. My current feeling is that the only good part at the current client would be to never go there again. Despite this, some events will have to make their way out as they're just too surreal.
Reblog this post [with Zemanta]

Wednesday, April 29, 2009


Wired plug board for an IBM 402 Accounting Mac...Image via Wikipedia

This article brought a few analogies to the fore.

Test automation is usually implemented in a bulk manner - more tests, faster, get coverage. What you ultimately get is a huge load of tests with a maintenance nightmare and possibly dodgy execution. Even the leaner approach of only automating what makes sense doesn't remove the underlying issue.

It is only with a smarter implementation strategy that one can achieve the purported benefits of test automation. An engine provides a stack of reusablity. Reusable components have been vouchsafed within software programming as being an ideal since the advent of the first function.

While the marketers try to spin the opposite story, test automation is effected by writing a program to test a program. Why then are the basic premises of good software design so commonly avoided in test automation?

I will continue to advocate an approach to test automation that results in a fitter test suite than a test suite bulking program.
Reblog this post [with Zemanta]

Tuesday, March 3, 2009

A lesson in error trapping

~ Spring Thing ~Image by ViaMoi via Flickr

One would think that this is something that doesn't require much. If you don't handle errors in your code it will turn into a nightmare. Sure I do know this but today I discovered that there's still the odd lesson out there.

The situation... quite simple really. Have a call to a function that gets a value from an Excel spreadsheet using the ADO interface. If things go wrong the function returns the error as reported by ADO. So everything is just peachy. Even more so when you notice that there is a check on an error state to the function. All handled - or so it would seem.

The "where the heck is Kansas" question arose out of the fact that the call on a specific spreadsheet was always had a null value. Pointing to a different spreadsheet and a value is suddenly there again. Very surreal situation. File name changes, different values being queried, copying the values into a new file as well as changing the search key values refused to change the situation. Believing that the file itself was whacked didn't help when a copy of the content to a new workbook also returned the same lovely blank entry.

Eventually went back to the function call and added code to display the function return value. The light in the tunnel. There is an error on the query and it quite cryptically claims that there is too much data. Back in the spreadsheet and one Ctrl-End later we find that there is a white space character in column IV (the limit in Excel 2003). Few hundred deleted columns later the script is working as it should.

With a little "else" added to the function code and suddenly tracking this error would not have been such a surreal journey. The error is now being nicely reported in the execution report and this likely solves some of the frequent mysterious errors (like "Object required in appDict(...)") that pop up.

If's really can not divorce the catch all else.

Pity that VBScript doesn't have cool tools like a unit test module as well as some form of mock objects (for dealing with QTP GUI interaction results).

Monday, February 23, 2009

Getting to SWIFT

Giraffe's Goofy Grin!Image by ucumari via Flickr

SWIFT has been a background idea. Ultimately what is needed is a means of generating a message with known input as well as checking a received message against some expectations. After running into WIFE last year I figured that the process was imminently simplified. Time, however, can be a nasty thing.

With two projects boiling away with furious vigor, it has become time to get the basic SWIFT message validation tool written. This is not due to father time having changed his ways but both systems I'm working with showing an impending need for it.

I must say there's been an auspicious start... the OS library hadn't been touched in a while. Not much to fear though since SWIFT doesn't change all that often. False confidence on my part. After popping a sample into Eclipse all that would return was a simple class not found error.

Yay for open source in that I could pop the source into a project and try figure it out. Turns out that there was a dependency on Java 1.4. Ultimately a simple update to the Java version and the classes can no longer hide from the compiler.

So now I just need to figure out how the library works... It would probably help to get a good understanding of how SWIFT messages are put together before doing this, but the clock is ticking. Heck now that I have undone my assumption that the newlines between tags within the message fields are simply there for readability the way forward is looking almost too good to be true.

Wednesday, February 11, 2009

A use for spam

Thursday, January 15, 2009

Spinning a JavaSpin field with QTP

On the other side of the sea...Image by Tonyç via FlickrSometimes its good to be reminded that there are things out there that simply just don't want to work. These always present a challenge. The most recent example is a simple case of a Java application with a spin button for selecting the time with the obvious requirement of being able to set a value. Hmmm...

Spin fields are created as a combination of a couple of buttons inside of an edit field. Rules are then applied to the buttons in terms of their effect on the value. Rules also apply to the value itself. Simply though, there are 4 objects within this one field. The container which is the spin control. An edit field for the value. A button for increasing the value and another button for decreasing the value.

QTP was not happy. There is a Set function that works on the spin object and should set the value of the control. Now while GetROProperty("value") works, the Set function does not. It actually would have been nice for it to have failed with an error rather than doing nothing.

Another simple option also exists... set the edit field to the value. This would have been great except that the Set function for the edit was reported as being invalid - the joys of a composite Java field.

Reblog this post [with Zemanta]
Since every specific object in QTP is simply an extension of the object type, it would seem reasonable to try switching to that level. Another failure. The object can be found but setting the value results in an invalid method failure.

Well ultimately setting a value simply requires that the object be activated and then a Type should work. Now QTP does not provide activate functions for all the Java objects. Not a big deal as an activate is the same as a click on the object.

Ha! Not this time. The click function, which is nothing more than a simulation of a mouse click would not activate the spin field. This was a weird one. Seriously surreal.

OK. Going back to the spin control. QTP provides functions for Next and Prev values. I know already that running these functions does not change the spin field - probably just as well as I would probably have been able to set the hour but would have been unlikely to have accessed the minute field. This exploration did however show a flicker in the field.

Regardless of testing you work in, noting any effect/flicker/change in the application is essential. This flicker lead to the solution... as weird as it turned otu to be.

The solution involved the following:
  1. Run the spin object's next function
  2. Send a home keypress to the window by typing micHome to the Java window object
  3. Type the value to be captured to the Java window
This worked great... on one field. Testing against the second spin field on the same page resulted in more weirdness. The value "2121" was being typed as "121n" (where n was the original value at that position). Running the test code twice though, captured the value correctly. I checked this bizareness three times and in each case, the first field was perfect the second was not.

The implication was to obviously run the type portions twice against the spin field. So the final solution turned out to be:
  1. Run the spin object's next function
  2. Send a home keypress to the window by typing micHome to the Java window object
  3. Type the value to be captured to the Java window
  4. Send a home keypress to the window by typing micHome to the Java window object
  5. Type the value to be captured to the Java window
Its interesting that most solutions to seemingly intractible problems are actually extremely simple. Pity that they're not obvious.

Monday, January 5, 2009

Notes Abound

Alpha sixImage via WikipediaMoving from a client site can be a tad frustrating. You organized the email, notes, documents, code, and various other things to made the project work easier. Then off you go to somewhere else potentially leaving a whole slew of necessary items behind. This particular move has been somewhat interesting.

I've essentially moved between departments but I started with the other department with about 6 weeks to go till the end of my tenure within the original area. The company is very compartmentalized. Computers do not flow between areas. So the loss of potentially critical data was of some real concern. Email was a probable problem - inbox size limits seem to be met if the excessive measure of a weekly archiving is not brought into effect.

Retroactively working through 14 months of data can be down right daunting. Hopefully the system adopted will remove this problem. The idea is to print any important and relevant emails to PDF and to save them with the project data to a project folder. This should make all data for a specific project available in a central store.

Meetings are always a problem. For now I've synchronized the work calendar to my Google calendar. While I'm not sure about this it has proven to have been a prudent move as access, email, etc have not yet been sorted out for the new department.

Reblog this post [with Zemanta]