Software Testing Blogs: Load Testing, Unit Testing, Functional Testing
In this blog post, Adrian Smith discusses 7 pitfalls of automating software testing. The seven sins are over indulging on propriety testing tools, too lazy to setup CI server to execute tests, loving the UI so much that all tests are executed through the UI, jealously creating tests and not collaborating, frustration with fragile tests that break intermittently, thinking automated tests will replace all manual testing, too much automated testing not matched to defined system quality.
In this blog post, Jens Schauder shares some tips based on experience to improve the testing of database code. People seem to understand the need to test their code, but apparently this is not yet the case for the the database code, because database tests tend to be slow, interdependent and hard to maintain
This blog post give a detailed code on how to distribute Robot automated acceptance tests to several virtual box instances using Chef. Pavlo Baron explains how using Vagrant and VirtualBox as a poor’s man virtualization and wiring with Chef, you can run in parallel your acceptance testing suite in a distributed environment.
The testing strategy to adopt when you you run your code inside a Java EE container is the topic discussed in this blog post by Antonio Goncalves. To solve this issue, he presents a detailed step by step process to unit test an EJB with Mockito and how to do integration test with and without Arquillian with code samples. His conclusion is that since Java EE 6 it is now easy to use container and services in an embedded mode. Unit testing is good to test business code or code in isolation (mocking external components) but you have to remember that you should also use integration testing to test code interacting with external components or services.
In this blog post, Rob van Steenbergen add his humorous input to the current debate about the death of software testing. He mentions a lot of reasons why we should stop testing like: * a user will follow the manual strictly * a user will do no strange things with the software * a user will not make mistakes using the software Find many other reasons of this type in his blog.
Every month, 50% of the Google code base changes. This is a lot of code and a lot of people. In order to ensure that its code base stays healthy, Google uses a bug prediction algorithm. This blog post discusses how Google develop this machine-learning and statistical analysis tools that tries to guess whether a piece of code is potentially buggy or not, usually within some confidence range. Bug prediction is not an objective measure by any means, but it is used to place a warning in our code review system on specific files. Whenever a reviewer logs in to review that code, the warning will appear, which hopefully will encourage them to spend some more time reviewing the code or hand off the review to someone more experienced if need be.
This blog post by Andrey Shevchenko provides an overview on how to write functional tests for Groovy using Geb and Spock technologies with a detailed example. Geb is a browser automation solution that brings together the power of WebDriver, the elegance of jQuery content selection, the robustness of Page Object modelling and the expressiveness of the Groovy language.
