Software Testing Blogs: Load Testing, Unit Testing, Functional Testing

A Baseline Approach to Software Testing

Software Testing Magazine — Mon, 09 Oct 2017 17:08:39 +0000

Unit testing and Test-Driven-Development (TDD) are an important part of every Agile software testing strategy. One of the issue associated to these techniques is the coupling between the source code and its tests. In his blog post, Tingan Ho presents a testing strategy, called Baseline Testing, that should solve the coupling issues with TDD. The ideas of Tingan Ho are based on the testing strategy of the TypeScript compiler. This blog post starts with some basic information about automated testing and the type of problems that it creates for software developers. One of them is that the validation of the unit test is included in the test code. If the source code changes, then you need to change your testing code. In the Baseline Testing approach, tests record and store all results and match them with a reference baseline, which consists of the previous accepted test results. Baseline Testing does the contrary to TDD as it fits the tests after the source code. However, Tingan Ho writes that his approach allows to be more productive than TDD. His conclusion is that “Baseline Testing is a bold, but very effective strategy. It is bold because it questions an historic sound testing strategy — TDD. It is effective, because with just a press of a button, you have created new test verifications. What took hours and days to refactor with TDD - now only take seconds to do with Baseline Testing.” Read the complete blog post on https://medium.com/@tinganho/baseline-acceptance-driven-development-f39f7010a04

The post A Baseline Approach to Software Testing first appeared on Software Testing Magazine.

Test Automation Starts with Unit Testing

Software Testing Magazine — Mon, 25 Sep 2017 15:28:57 +0000

Even if they are at the basis of the software testing pyramid and they are at the heart of the Test-Driven Development (TDD) approach, unit tests are still a controversial topic in software development and some people event consider that most unit testing is waste. In his blog post, Bas Dijkstra explains why he thinks that unit testing should be the basis of any solid automation strategy. Bas Dijkstra starts by explaining that unit tests are easy to write and fast to run, the opposite of integration or end-to-end (E2E) tests. Unit tests have also a positive influence on code. If you want to improve the testability of your code, you need to improve its structure. This virtuous circle means also that when you write clean code, it is easier to write tests for it. Finally, unit tests are the basis for integration tests and refactoring. When your code enter a maintenance phase, having unit tests acts as a safety net that should make sure your changes are not breaking individual functionalities. His conclusion is that “In the end, unit tests can, will and need not replace integration and end-to-end tests, of course. There’s a reason all of them are featured in the test automation pyramid. But when you’re trying to create or improve your test automation strategy, I’d advise you to start with the basis and get your unit testing in place.” Read the complete blog post on https://www.ontestautomation.com/why-i-think-unit-testing-is-the-basis-of-any-solid-automation-strategy/

The post Test Automation Starts with Unit Testing first appeared on Software Testing Magazine.

Automating Cross-browser JavaScript Unit Testing

Software Testing Magazine — Mon, 13 Feb 2017 16:20:26 +0000

What might seem obvious to some people could be weird to other. This is still the case for applying unit testing to JavaScript code in multiple browsers. In his blog post “Learning How to Set Up Automated, Cross-browser JavaScript Unit Testing”, Philip Walton provides a step-by-step approach process to create some automated testing of your JavaScript code. Philip Walton thinks that even if there some JavaScript testing tools and frameworks, like Karma, that claim to make it easier to automated JavaScript tests, his experience is that these tools create often more complexity. The blog starts with a definition of automation as “using machines to off-load the repetitive parts of an existing workflow”. He makes very interesting and fundamental remark: “If you try to start with automation before fully understanding the manual process, it’s unlikely you’ll understand the automated process either.” The post continue with some examples of testing using Mocha. The problem in this simple approach is that when some of your tests are failing, there is no easy way to reproduce your bug and debug locally. It is also tedious and error prone to open different browsers to run your tests every time you change your code. Philip Walton then describes a process that meet his requirements * running the tests from the command line. * debugging failed tests locally. * running the tests on a CI machine * being able to run all the tests automatically anytime somebody commits new changes or makes a pull request. This process [...]

The post Automating Cross-browser JavaScript Unit Testing first appeared on Software Testing Magazine.

Testing Infrastructure at Google

Software Testing Magazine — Tue, 06 Dec 2016 14:23:21 +0000

One of the activity of software testing engineer at Google is to build and improve the test infrastructure to help software developers to be more productive. In this blog post, Jochen Wuttke gives a concrete example of this task. In one of his project at Google, Jochen Wuttke was responsible to understand the software testing issues associated to the maintenance of a legacy system. He discovered two main causes: * Tight coupling and insufficient abstraction made unit testing very hard * The infrastructure used for the end-to-end tests prevented to create and inject fakes or mocks for these services. The blog post describes three solutions that he explore to solve these issues. He gives more details about the solution that was retained, how he implemented it and what results were achieved. His conclusion is that “Building and improving test infrastructure to help engineers be more productive is one of the many things test engineers do at Google. Running this project from requirements gathering all the way to a finished product gave me the opportunity to design and implement several prototypes, drive the full implementation of one solution, lead engineering teams to adoption of the new framework, and integrate feedback from engineers and actual measurements into the continuous refinement of the tool.” Read the complete blog post on https://testing.googleblog.com/2016/11/what-test-engineers-do-at-google.html

The post Testing Infrastructure at Google first appeared on Software Testing Magazine.

How to Give Better Code Reviews

Software Testing Magazine — Mon, 24 Oct 2016 15:14:45 +0000

Wikipedia defines code review as a systematic examination of computer source code to improve the overall quality of software. In his blog post, Joel Kemp provides some propositions on how to give better code reviews. Joel Kemp starts hist by explaining that code reviews are a key tool create knowledge transfer and spread best practices throughout a development team. There are at least two phases in code reviews and most people stop at the first and less valuable phase where only the obvious issues are examined. The second phase is the contextual pass where participants examine issues like adequate usage of frameworks/libraries or a satisfactory test coverage. During this phase, Joel Kemp advice to be cautious of how you ask questions: you should suggest approaches or provoke exploration and not try to deliver solutions. The conclusion of the post is that “[…] reviewing code is as much of a craft as writing code. As reviewers, it’s our mission to improve on a number of fronts: our ability to understand code; our process, awareness, and criteria for analysis; and our teammates’ ability to write correct diffs.” Read the complete blog post on https://medium.com/@mrjoelkemp/giving-better-code-reviews-16109e0fdd36

The post How to Give Better Code Reviews first appeared on Software Testing Magazine.

Replacing Rules in JUnit 5

Software Testing Magazine — Tue, 17 May 2016 16:26:02 +0000

Rules have disappeared in the version 5 of the JUnit open source Java testing tools. The release 5 of JUnit is still in alpha status. In this article, Herrmann Rüdiger explores what it would take to transform existing rules to the new concept so that they could run natively on JUnit 5. The article starts by explaining extensions, a new concept in JUnit. These extensions will be a good way to replace rules in JUnit and the blog post provides many code examples on how to achieve this goal. An interesting new features is that JUnit 5 provides a means to maintain state of extensions called Stores. Stores provide methods for extensions to save and retrieve data. The conclusion of the blog post is “extensions are a decent and complete replacement for rules and friends in JUnit 4. And finally, using the new methods is fun and feels much more concise than the existing facilities. […] But note however, that as of this writing extensions are work in progress. The API is marked as experimental and may change without prior notice. Thus it might be a bit early to actually migrate your JUnit 4 helpers right now – unless you don’t mind to adjust your code to the potentially changing APIs.” Read the full blog post on http://www.codeaffine.com/2016/04/06/replace-rules-in-junit5/

The post Replacing Rules in JUnit 5 first appeared on Software Testing Magazine.

The End of End-to-End Testing

Software Testing Magazine — Thu, 04 Feb 2016 16:15:31 +0000

End-to-end testing (or system testing) tests a completely integrated system to verify that it meets its requirements. In a blog post, Mike Wacker from Google explains why if this testing strategy sounds good in theory, it goes wrong in practice. The blog post starts by remembering what are the reasons to perform end-to-end testing. This is mainly because tests that simulate real user scenarios can help to easily determine how a defect could impact the user. To explains why this doesn’t work in practice, Mike Wacker presents an example based on his own experience. He explains that failing tests do not benefit the users, but only fixing bugs provides benefits. His advice is that “Thus, to evaluate any testing strategy, you cannot just evaluate how it finds bugs. You also must evaluate how it enables developers to fix (and even prevent) bugs.” He presents then the famous testing pyramid and explains why you should focus on unit tests rather than system tests. His conclusion is that “As a good first guess, Google often suggests a 70/20/10 split: 70% unit tests, 20% integration tests, and 10% end-to-end tests. The exact mix will be different for each team, but in general, it should retain that pyramid shape.” Read the complete blog post on http://googletesting.blogspot.ch/2015/04/just-say-no-to-more-end-to-end-tests.html

The post The End of End-to-End Testing first appeared on Software Testing Magazine.

Unit Testing a Require.JS App

Software Testing Magazine — Mon, 09 Nov 2015 16:52:57 +0000

Require.JS is an open source JavaScript file and module loader. In this blog post, Ben Wilhelm explains how to add unit tests to a Require.JS application without spending a large effort in refactoring the apps. The blog post start by explaining the difficulty to add unit tests to an existing application, more particularly the issues with mocking the dependencies in your the subjects. The blog post explains how the New York Times development team added unit tests to a Backbone.js javascript application. It contains a lot of code examples. It deals more specifically with the usage of the Spire.js library to sole the mocking problem. Spire.js is an open source dependency injector that can be used to test Require.js modules. The conclusion is that “Squire provides an easy-to-use, compact API for mocking RequireJS modules. Since all of our application components are RequireJS modules, Squire allowed us to make all of our dependencies injectable at once, without making any changes to our source code. This spared us a considerable amount of refactoring in order to make our application testable.” Read the complete blog post on http://open.blogs.nytimes.com/2015/01/15/how-to-unit-test-a-requirejs-application/

The post Unit Testing a Require.JS App first appeared on Software Testing Magazine.