More information I agree
Automated testing

Automated testing

Why opt for automated testing?

A web application consists of many – often complex – functionalities that are built using code. Obviously, this code is extensively tested before the application is put into use. When adding new functionality or new pages, it’s efficient to reuse parts of this code in slightly modified form.

When reusing code, the original functionality may have become corrupted. This type of regression bug may seem easy to solve, but ultimately, an application will become too comprehensive to test everything manually from scratch for every adjustment you make.

So, our Scrum teams use automated tests, which are faster and more thorough – an automated test doesn’t ‘forget’ anything. This means we deliver better quality software faster.

Unit tests, integration tests, and behavior tests

You can test at several levels. It’s possible to test individual components or the bigger picture. A unit test is used for classes of methods, individual pieces of code. An integration test is used for functionality. A functionality in an application is formed by the integration of classes/methods that communicate with each other.

These two tests are used for either front end or back end. The next step is to test at the user level. Does the application work as expected? This is called a behavior test – or, for web applications, a browser test.

To perform these three types of tests, we use PHPUnit, a test framework for the PHP programming language. In addition, we use Laravel Dusk for the behavior test.

Writing test plans

The written test plan is a detailed, human representation of behavior tests that can be used for the website or application. Describing them means we can subsequently automate them.

For every test plan, we first define:

  • The desired OS/browser combinations (for example, ‘Windows 10 combined with Microsoft Edge 15’)
  • The user roles that need to be tested (for example, ‘visitor’ or ‘admin’)

Then we write out the following for every test: the URL where it will be performed, the active role, the action(s) that will be carried out, and the expected test result. And of course, every website’s or application’s test plan is extended with the new functionalities or components that should be tested.

Example 1: a behavior test

  1. 1. On the URL www.ditismijnapplicatie.nl, I look at the login form as if I were a visitor.
  2. 2. I complete the form: ‘Email address = user@way2web.nl’ and ‘Password = wMFQsXuuoeav1qYKOq’.
  3. 3. I click on ‘Log in’.
  4. 4. I expect the ‘/dashboard’ page and read ‘Welcome back’.

Way2Web login test

Example 2: a behavior test in code

/**
* Tests that a user can login successfully to the application.
*/
public function testLoginForm()
{
$this->browse(
function (Browser $browser) {
$browser
->visit(‘www.ditismijnapplicatie.nl’)
->waitFor(‘@login-form’)
->type(’email’, ‘gebruiker@way2web.nl’)
->type(‘password’, ‘wMFQsXuuoeav1qYKOq’)
->click(‘@submit’)
->waitFor(‘@welcome-text’)
->assertSeeIn(‘@welcome-text’, ‘Welkom terug!’);

$this->assertEquals(‘www.ditismijnapplicatie.nl/dashboard’, $browser->driver->getCurrentURL());
}
);
}

Code coverage

Briefly put, the code of an application is tested in an automated way at several levels. Once you’ve ‘covered’ 80%-90% of the application, the code coverage is good, as not all code is equally important for testing purposes. The final 10%-20% barely add any value.

Way2Web Code coverage

Way2Web uses tools to measure the code coverage.

Incidentally, we discuss the required percentage with the customer. It is included in the Definition of Done, in which we determine when an application is ‘finished.’ The percentage that represents sufficient quality depends on the type of application and project.

Just to be clear, code coverage is an indication of how much code has been tested and says nothing about the quality of the tests. For example, you can use this test to see whether the application works when a user does what they’re supposed to do. Testing expected behavior is also referred to as the ‘happy path.’ It doesn’t provide insight into what happens if the user does something unexpected. And you will want to be prepared for that scenario, too!

Are you ready for the next level?

Digital transformation presents fantastic new possibilities and opportunities. Both for our company and yours too. As an IT specialist and entrepreneur, I would like to discuss this further with you, without any obligation, of course. Shall we make an appointment?