Thursday, December 20, 2012

Unit Testing the TestFramework

Now what sense does this make!?  Doesn’t our tests prove our TestFramework methods and/or functions work!?  My reply would be “is your test only verifying a portion of the functionality or all of the intended functionality?”First, let me provide a definition of TestFramework for this article.  A TestFramework is an advanced automated test solution that is often a library of classes, methods, functions with dependencies designed to provide behavior driven support to test an applications’ features and/or objects and is often driven by test data or keyword-type tests.  In addition, a TestFramework can also provide advanced helper support by providing access to web services, databases, middleware applications, or utility functions e.g. copying files.  The bottom line, TestFrameworks have evolved to be application systems and infrastructures that are designed to test not only test applications but also aid in the preparation for tests, tear down after the tests and report errors of unintended behavior.  I have even seen TestFrameworks that also generate their own testdata, manage timeline dates, perform advanced statistical calculations, incorporate security and load testing, and manage the machines under test.  We’ve come a long way from simple GUI-level testing and record and playback!
Given that our TestFrameworks has evolved beyond record and playback, unit testing can help to ensure that the TestFramework’s provided methods and/or functions (depending on the language of choice) works as we intended at its basic level.  The benefits for doing this extra step is:
  • Your unit tests can verify the codes conditional statements, loops and exception handling behaves as intended.
  • If your TestFramework logs an error or results in unintended behavior, you now have a non-integrated snippet of code you can use to test and debug your methods.
  • If you methods/functions require an upgrade, you can use your unit tests to verify the upgrade works as expected.
  •  You can run your suite of unit tests to verify the entire TestFramework prior to performing an actual test run.
  •  You can leverage your code management and build management systems to help you automatically run your unit tests after submitting your changes.
  • Last, it definitely can help you reduce the time you spend analyzing reported problems as you will not need to double-check if the problem is in your Framework.
For those of us new to test automation, you can learn more about unit testing here http://en.wikipedia.org/wiki/Unit_testing.
So think of unit testing as a time saver and a way to always verify the health of your TestFramework.  It can definitely fend of the common arguments of “maybe the bug is in your tests J.”  Begin developing the habit of when you create new methods, develop a unit tests to verify it.
Happy Automation!

No comments:

Post a Comment