This is not a session about how or why to practice Test-Driven Development (TDD). Based upon research conducted during the first quart of 2012, I will outline the most common objections to TDD and describe in detail, with examples where appropriate, how to refute, avoid or mitigate each of them. The coverage will acknowledge that there are risks inherent to all techniques and will not promote the idea that TDD is some kind of silver bullet.
Marcus Martina explains in this blog post how to integrate FitNesse tests into the Jenkins continuous integration system. FitNesse is an open source testing framework that aims to implement integration testing in a collaborative way. It is easy to integrate FitNesse tests automatically with Maven and Jenkins. The post provides the code necessary to do this integration. It also identifies the different Maven plugins that are necessary to achieve this goal and recommends to trigger the execution of the integration tests in an individual build step.
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.
Copyright © 2009-2024 Software Testing Magazine by Martinig & Associates