This extract from the book “Pragmatic Unit Testing in Java with JUnit” written by Andy Hunt and Dave Thomas provides an introduction to the usage of mock objects during Java unit tests. They define the usage of mocks in unit testing as the unit similar to the use of lighting doubles in the movies: A mock object is simply a debug replacement for a real-world object.
In this blog post, Dror Helper presents a short “getting started” procedure to do Behavior Drive Development (BDD) with SubSpec. SubSpec allows developers to write declarative tests operating in C# at all layers of abstraction consisting of highly composable, small primitive concepts. SubSpec is based on the xUnit testing framework and can easily be integrated into existing testing environments. The blog post shows how to write its first behavior test and how to run all the assertions in one test.
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.
Copyright © 2009-2024 Software Testing Magazine by Martinig & Associates