Or else your users will find your bugs the hard way – by crashing into them. And I don’t think anyone wants to see its app go up in flames because of some sloppy developer that forgot to test its library.
Automated tests are a good thing because they can be ran on their own – either fully automatic, like when you check in a new part of your project, or with a single command by the user. They are repetitive, deterministic and, hopefully can provide with a simple passed / failed result. The problem right now was to find a framework that could take care of creating the test harness, so we could only throw test-cases at it and check out the results. And the winner was JSUnit, which, albeit some time lost because we didn’t RTFM, proved to do everything we wanted:
- It has a Java component which allowed us to set up the tests to kick-start with a simple ANT task.
- Its build.xml file allowed easy setup of the machines on which to run the tests and the paths to the browsers in which to test (yes, you can call different machines with different browsers).
- It automatically saves each browser’s result as an XML file which can be parsed / checked later on. This seems to be a great thing, as it allows us to integrate with the existing test suites which use JUnit.
What this does not do is test the UI for you. It is built on the principles of JUnit, with the differences inherent to the programming language it addresses. So you can have test pages and test suites. A test suite is composed of multiple test cases, each on its own page. And to drill it down, each test is in fact a function – which must have its name start off with test.