Software Testing Articles, Blog Posts, Books, Podcasts and Quotes
Bradley Braithwaite shares in his blog a step by step process to perform JavaScript unit testing in the Eclipse IDE with QUnit and JS Test Driver. QUnit is a powerful, easy-to-use, JavaScript test suite. It’s used by the jQuery project to test its code and plugins but is capable of testing any generic JavaScript. The goal of Js Test Driver is to build a JavaScript test runner that easily integrates with continuous builds systems and allows running tests on multiple browsers quickly to ease TDD style development. Starting from the opening of the Eclipse IDE to writing the tests, everything is explained with code examples. Bradley adds also at the end some productivity improvement tips like code template or avoiding the browser. He also recommends using a tool like JSLint or JSHint to manage code quality. JSLitmus is recommended to profile JavaScript code for performance tuning.
Codan is a code analysis framework that performs code checks on C/C++ projects. It is part of the Eclipse CDT (C/C++ Development Tooling) suite since 2011. Codan was updated with the Eclipse Juno release in June 2012 to enable developers to automatically execute external code analysis tools within Eclipse. In this article, Alex Ruiz explains why the update is good news for users of Eclipse CDT, then shows you how to use Java code and a little bit of XML to quickly integrate your favorite code checker into your Eclipse C/C++ development environment, using Cppcheck as an example. The article provides a detailed step by step process to achieve this goal that requires just about 100 lines of simple Java code and 30 lines of XML.
James Whittaker is a former engineering director at Google and has been responsible for testing Chrome, Google Maps and Google Web Apps. In this book written with Jason Arbon and Jeff Carollo, he describes how Google organizes its software testing process. The Google software testing organization that has three roles: Software Engineer in Test (SET), Test Engineer (TE), Test Engineering Manager.
In this blog post, Rui Sun and Andre Hamilton explore some Visual Studio 2012 capabilities that will make it easier to test and verify Windows 8 applications. Visual Studio 2012 has a simulator that reduces your need to have physical devices of every form factor at your disposal for testing. You can launch your application in the simulator directly from within the Visual Studio through the debugging action. Then you can interact with your application using the mouse or using simulated touch on your development computer with gestures like swipe, pinch to zoom and rotation. Visual Studio also provides a unit test library project for Windows 8 applications written in C#, VB.net or C++.
Adobe Shadow is a new tool currently developed by Adobe that provides developers a way to inspect and debug from their desktops wirelessly and synchronously across multiple devices. The Adobe Shadow desktop application listens for changes in a URL location in the browser. When a change occurs, it pushes the new URL out to all wirelessly connected devices immediately so the changed content is seen on the devices immediately. In this blog post, Holly Schinsky provides step-by-step instructions on how to use Adobe Shadow to inspect and debug your mobile code.
There are solutions which provide the ability to automatically run your tests as you code. This tutorial shows how to use a Ruby gem, called watchr to monitor your code and automatically run the appropriate tests whenever you save your work. This is how you can automated Test-Driven Development (TDD) on your PHP code. The watchr gem is an executable program written in Ruby, and it wraps around features found in an operating system’s file system to provide the ability to watch for changes made to a specific file or folder. The tutorial provides a step by step approach on how to use it and integrate it in your PHP coding activities.
You might want to begin by choosing the tool you want to use when you want to introduce ATDD to a project or client. In this article, Markus Gaertner says that this doesn’t work and shares his advice on how to overcome the biggest mistakes from the beginning when you get started with ATDD. He recommends to start with an example. Working together, the team identifies a case that would derive the greatest benefit from being automated. You should define the right approach first, the right people second, the right format third. The format we choose will limit the choice of the tool, but the tool itself should be our last consideration. Instead of thinking about the tool, we should work for clarity in how we write down our examples. All the successful teams he has worked with on ATDD shared one thing: they started with one approach, and they reflected on it regularly. During those retrospectives, they came up with necessary improvements if the approach stopped working for them. If you keep this practice in mind, you can essentially start with any approach.
