An Ubiquitous Domain language throughout testing

One of the biggest challenges as engineers is to write working software and also keep an extensive documentation. Most engineers hate writing documentation, and after they published documentation on a wiki it will die a lonely death. We want to strive for writing a Living Documentation in an Ubiquitous Language. Practices like Domain Driven Design (DDD) and Behaviour Driven Development (BDD) can help you achieve this. Especially when we start writing code, it is really important for the quality of our software to start with tests describing what your application does. We want to write software with empathy in mind, software that is understandable for peers. While software developers are beginning to use the language of the domain (business language) more in their application code, most tests still contain a lot of technical language.

Read more →

Misvattingen rondom testautomatisering - Misvatting 1: The Silver Bullet

Deze blog post is de eerste in een reeks van posts ter wegneming van misvattingen rondom het thema testautomatisering. Zie hier voor het inleidende artikel.

Misvatting

Testautomatisering is de oplossing voor al onze problemen rondom testen en kwaliteit.”

Toelichting

Dit is helaas nog steeds een gangbare opvatting onder voornamelijk, doch zeker niet uitsluitend, ongeïnformeerde stakeholders op (lijn-) managementniveau. Daarbij blijft deze misvatting ook vaak onuitgesproken. Vanwege dit impliciete karakter, blijft deze zienswijze doorgaans lang bestaan, omdat zij niet (of te laat) onderkend en daarmee ook niet (tijdig) gecorrigeerd wordt.

Read more →

Misvattingen rondom testautomatisering - Introductie

De geschiedenis van testautomatisering beslaat inmiddels een periode van enkele tientallen jaren. Deze discipline is echter pas de laatste jaren écht in een stroomversnelling geraakt en ze lijkt nu voor het eerst ook definitief door te breken en zich te bestendigen, als een relatief volwassen vakgebied.

Deze ontwikkeling is een gevolg van onder andere de maturatie van tooling en frameworks, de adoptie door grote spelers zoals Google en de succesvolle opkomst van software development methodologieën die testautomatisering als randvoorwaarde hebben of waarvan testautomatisering een logisch gevolg is.

Omdat testautomatisering in deze zin genomen nog maar een relatief jong vakgebied is, bestaan er binnen dat vakgebied nog steeds een hoop misvattingen (en daarmee valkuilen). Zelfs ten aanzien van allerlei fundamentele thema’s. Deze misvattingen bestaan in een organisatie vaak niet alleen binnen allerlei (hogere) managementlagen en groepen van (meer direct betrokken) business stakeholders (zoals product owners), maar zelfs binnen allerlei groepen van practitioners (zoals developers en testers).

Read more →

Property-based testing in Java with JUnit-Quickcheck - Part 1: The basics

To be able to show you what Property-based testing (PBT) is, let's start by grasping the concept of a property in programming languages. Since this is a Java tutorial, I will start with Oracle and their definition of a property in their glossary:

Characteristics of an object that users can set, such as the color of a window.

Property is neither a variable/field or a method; it is something in between which is always true in your context. An example is weight in a postal parcel: this always is greater than zero.  In Java the following example implementation would follow:

Read more →

Building, testing and deploying precompiled Azure Functions

Azure functions are great to build small specialized services really fast. When you create an Azure Functions project by using the built-in template from the SDK in Visual Studio you’ll automatically get a function made in a CSX file. This looks like plain old C# but in fact it is actually  is C# Script. When you’re deploying these files to Azure you don’t have to compile them locally or on a build server but you can just upload them to your Azure Storage directly.

In the last update for Azure Functions the option to build precompiled functions was added. Doing this is actually pretty simple. I’ve created a sample project on Github containing a precompiled Azure function, unit tests for the function and an ARM template to deploy the function. Lets go over the steps to create a precompiled Azure function.

Read more →

It’s 2017: Test automation is not optional when building mobile apps!

Note: although this post focusses on mobile app development using Xamarin it also applies to other native mobile apps built in Swift, Java or even web apps. it’s 2017! whatever you are building get started with Test Automation!

As a consultant working for Xpirit i get to see a lot of different customers which I help with my expertise in building mobile applications to improve their mobile apps. Something I noticed in the previous year is that continuous delivery is a hot topic and companies and teams focus on deploying apps automatically to their testers through hockeyapp or even to the stores in beta and / or production.

In agile scenario’s (and come on who isn’t doing that currently? Every company or project I visit is saying they are agile or doing Scrum although some only do dailies and call that scrum ) In the current world it is really important to be able to release often because you want to be able to adapt to customer needs which are almost always changing and evolving.

Read more →

Cypress - Dealing with flaky tests

Test automation is all about feedback. Feedback that gives you quality updates about the features your team has built. A continuous green build is always the goal because this should give you the confidence you need to go to production. Unfortunately, I’m more used to a “traffic light build”, a build which passes and fails intermittently, mainly because of flaky tests. That is one of the worst things about end to end testing in my opinion.

Why on earth do we still put software into production when we can’t trust our test automation?! Well, that's because we retry the build a couple of times until we have a lucky hit: the build is green and we’re ready to go to production. Although this is a solution, it still feels like a pretty silly thing to do.

Another option, which has my preference, is refactoring those tests until they actually work. The annoying part about this is that you don’t know what’s going on, and most of the time it is impossible to reproduce the failures. Reproducing them takes a lot of time debugging, analysing and mostly guessing where the problem is.

What if we could actually see what’s going on?

Read more →