Martin Flower defines legacy code as code without tests. You test your server-side code, but if you are working on a site with a fair amount of non-trivial JavaScript (ajax call, extensive callbacks, etc.) you really should be testing your JavaScript as well. All the untested JavaScript code we are writing today is, in effect, legacy code, but we can address this with JavaScript unit testing!
In this blog post, Martin Sikora shares his experience of performing Python unit tests on the Google App Engine (GAE). You can test such application locally in terminal, locally on GAE test server or on a real GAE production server hosted on Google infrastructure. To achieve this objective, he used nose, a tool that extends Python’s unittest to make testing easier, with NoseGAE, a nose plugin that makes it easier to write functional and unit tests for Google App Engine applications. The blog post provides the code to run the tests on a GAE server.
Best practices for unit testing are that you should only write for each test a single assertion. In this article intends, Jonathan Allen tries to demonstrate that unit tests with multiple assertions are both necessary and beneficial.
Breaking concepts down into logical chunks, tackling them in isolation. Sound familiar? This is how we write tests, but it’s also how a mathematician writes proofs. Exploring the similarities and differences between the two can bring us back to our profession’s mathematical roots.
In this blog post, Mark Prichard presents a solution on how to use Jenkins to give a “QA dashboard” view of a native Android application build. His goals were to show metrics for the results of unit test and code coverage in an Android build context on the Jenkins continuous integration system.
In this blog post, Jonathan Kohl discusses the similarities between software testing and game playing. He defines a game as a “situation involving cooperation and conflict with different different actors with different motivations and goals”. He sees software testing as an individual pursuit within a larger software development game and with two styles: scripted testing and exploratory testing..
Traditionally, software testing occurs after the software is written. From a Lean perspective, this is waste because the software needs to be reworked, retested and often reworked again. Instead, Lean says that quality should be built-in to the way of working.
Copyright © 2009-2025 Software Testing Magazine by Martinig & Associates