One great aspect of Siesta is its extensibility. It’s designed from the core to be customizable and overridable by anyone using it. After you have written a few tests, you likely find some repeated lines of code, violating the DRY principle. This is when you should extend the built-in Siesta test class. In your own test class you can put snippets of code that you use a lot throughout your tests, this is well described in our guide on how to extend the Siesta.Test class with your own abstractions. In this blog post I want to show you another cool trick you can use to do very cheap but useful sanity testing.

A recent bug report…

We recently had a bug report filed which caused a strange rendering artifact in the Scheduler component. In essence, the grid implementation stopped rendering properly. It felt really strange as we don’t override the rendering mechanism of the underlying Ext JS Grid class but after a while (a quite long while) we found the culprit. In one place we forgot to call Ext.resumeLayouts() after calling Ext.suspendLayouts(). This is a really tricky thing to debug and figure out, as this bug doesn’t cause any runtime errors – only visual unpredictable rendering quirks. Since I really didn’t feel like debugging this one more time, I decided to override the initialize template method of our Bryntum.Test class (which extends Siesta.Test). In this method I can easily inject a listener for the ‘beforetestfinalize’ event which is fired just before each test is completed. This gives us a great hook to do per-test sanity checks, such as verifying that no layouts are suspended. We use a bit of Ext.ComponentQuery to detect any components with layouts suspended:

The final snippet took about 5 minutes to write. Even better for you, as it’ll only take you about 5 seconds to copy paste this into your own Test class and you (and your customers) will never face this hard-to-debug rendering issue.

Any suggestions of other cool sanity tests that could be done this way? Let your voice be heard!

Happy testing!

  1. Tom Coulton 03/26/2014, 8:10 am Reply

    We’ve translated this article into Japanese here (日本語の翻訳はこちらです):

  2. John F 05/14/2014, 3:19 pm Reply

    When writing tests in BDD syntax, will this get fired at the end of every describe block?

  3. Nickolay 05/14/2014, 6:38 pm Reply

    Yes, it will be fired on the test instance of that particular test instance (which is provided for the function of the describe/it block). It will not however bubble up to the top-most test instance or harness.

Leave a Comment

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>