Click here to Skip to main content
13,590,079 members
Click here to Skip to main content
Add your own
alternative version

Tagged as


5 bookmarked
Posted 30 Nov 2011
Licenced CPOL

Getting Your App Continuously Tested

, 30 Nov 2011
Rate this:
Please Sign up or sign in to vote.
How to get your app continuously tested

Being able to identify issues quickly and having an automated system that tells us whether or not the application is broken sounds like a must have practice for software development companies nowadays. Nevertheless, we are still facing many challenges especially on large and complex systems.

So Where Do We Start?

In my opinion, the first step in getting automated is having a CI (Continuous Integration) system in place and making sure the builds cover major branches.

The CI system needs to be able to deploy and run the application in isolation per branches, for example using different virtual machines / databases. This way, we can make sure we have a known state of all resources and that we are able to roll back to that state after the tests run. Having the hardware/software resources needed for this is key to success.

In many cases, we may require changing the way the application is built and deployed, using tools and creating scripts that run steps automatically in CI.

Being Able to Run Tests Automatically in CI

Select the tools that allows you to run automated tests unattended and getting tests results reports in CI. This way, we make sure all the tests are executed after every code change, and that we are also able to run many tests on different environments/configurations.

Creating the Tests

Get the whole team involved and make the creation of different levels of automated tests a part of development activities. Consider the team may need to improve their code design skills, which leads to testable code. Most of us have heard high cohesion and low coupling, for a long time; unfortunately, it is common not seeing these applied.

Automated Tests General Guidelines

  1. The test should communicate intent: it should be clear and simple what the test is verifying, and how the functionality is used by the application.
  2. The test must have an assert.
  3. The test must pass and fail reliably. The test should not have code branches, i.e., if/else statements that cause it to not give a reliable pass/fail.
  4. If for some reason, the test has code branches, there must not be one that doesn’t have an assert.
  5. Keep tests independent: As tests grow, running the tests sequentially may be unpractical, so we need to make sure we can run tests in parallel and get quick feedback.
  6. There must be a way to run separately unit, integration and end to end tests. The distinction between these must be clearly understood.
  7. Unit tests must run fast.
  8. Do not comment tests when they start failing, fix them.

This list can grow very long but at least this can be a good start. =)

Hope this summary helps you and your team in getting automated.


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

Denmark Denmark
No Biography provided

You may also be interested in...


Comments and Discussions

-- There are no messages in this forum --
Permalink | Advertise | Privacy | Cookies | Terms of Use | Mobile
Web03-2016 | 2.8.180618.1 | Last Updated 30 Nov 2011
Article Copyright 2011 by mariangemarcano
Everything else Copyright © CodeProject, 1999-2018
Layout: fixed | fluid