[This message was posted by n d of <[email protected]> to the "General Q/A" discussion forum at http://fixprotocol.org/discuss/22. You can reply to it on-line at http://fixprotocol.org/discuss/read/af6286f5 - PLEASE DO NOT REPLY BY MAIL.]
Hi: We're at that stage where manually testing our API is getting tedious, especially with new releases where the same tests have to be repeated. I was having a look at quickfixj and they have a good 'acceptance test' suite mechanism that has 'i' (inputs) and 'e' (expected output) 'def'inition files. I was wondering if anyone has evolved quickfixj or created a simple tool where one can specify the 'input' and 'expected output' for application-level messages to build a suite of repeatable functional tests. Obviously, I could spend some time and build it but this seems so integral to the process that I'm certain many might have already walked this road to share their valuable experiences. So essentially --> a program that connects to a fix engine, reads a set of 'input' and 'output' fix messages (out of a flat-file) and determine if the cases passed or failed. If there is something out there that is opensource - that's even better. Thanks for your time! [You can unsubscribe from this discussion group by sending a message to mailto:[email protected]] --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Financial Information eXchange" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/FIX-Protocol?hl=en -~----------~----~----~----~------~----~------~--~---
