Testing without Siesta
When we first introduced tests to our deployment process we just did frontend testing using Selenium. The method was quite sufficient to guarantee a basic level of quality assurance and provides good automation features.
Inspired by a talk on the enterJS conference we decided to do more unit testing then. Our first approach was using the frameworks and tools presented in the enterJS talk, namely: mocha. This works quite well for code containing mainly JavaScript having not too many external dependencies. You can use various community contributed plug-ins to improve its functionality. But soon we had to deal with ExtJS, being used in almost all our code. Mocking away the ExtJS classes quickly became a tedious task.
Why we chose Siesta
Here Siesta comes into play. Bryntum’s test framework is shipped with full ExtJS support and can provide tests of all types, e.g. unit tests, user interface tests, you can even implement stress tests to ensure your middleware is able to take a certain request load. Because of its flexibility we plan to replace all test frameworks used until now and implement all future tests with Siesta. Integrated in our Jenkins based build server, Siesta has several benefits
Benefits of Siesta:
- assures that our application is not affected by updated third party libraries
- implements unit tests to support refactoring of certain modules
- supports our team of human software testers by covering monotonous standard test cases with automated tests.
- quality assurance: ensures that breaking changes to code surface early during nightly tests, including notifications sent to the developer who submitted the faulty code.
- after fixing a bug, Siesta makes sure that it “stays” fixed by implementing a test case tailored to the issue
Our future plans include extending tests to less covered parts of our application and to work towards a test driven development process which focusses on implementing the tests for new modules first