testing

Use Case best practice: Test your Use Cases with real data

Quite often when I’m asked to review a UML “Use Case” that someone else has written, I ask “Have you tested your Use Case with real data?” Sadly, the answer is usually “no.”

I don’t know why people don’t do this, but they don’t, and it seems like a very logical thing — essentially a unit test for Use Cases.

Testing takes time, just like structural analysis takes time

“Testing takes time, just like structural analysis takes time. Both activities ensure the quality of the end product. It’s time for software developers to take up the mantle of responsibility for what they produce. Testing alone isn’t sufficient, but it is necessary.”

~ Neal Ford (as seen on this tweet)

Seven benefits of automated GUI testing

Table of Contents1 - Benefits of automated GUI testing2 - Keys to automated GUI testing and continuous integration3 - Beware automated GUI testing software sales pitches and recorders

Introduction: I first wrote this article about automated GUI testing many years ago, but I find that it still holds today.

I just wrote most of the following note on the Apple Mac Java-dev mailing list, and I'd like to share it here as well, because I think it captures my thoughts on the benefits of automated GUI testing and GUI testing software.

I ran automated GUI tests part-time (4-6 hours per week) on a project with 8-12 developers, and saw some good benefits. True, in the 80/20 rule, 80% of the problems were due to UI changes and communication, like “We forgot to tell you we split the Name field into First Name and Last Name,” but with a good automated GUI testing tool, one test may fail, but the rest of the automated GUI test suite keeps running (see Fowler’s continuous integration). Furthermore, with a good GUI testing tool, something like this is also a minor change to get the test running again.

The Scala community build project

Scala community build is an interesting project, which is described like this:

“This repository contains configuration files that enable us to build and test a corpus of Scala open source projects together using Lightbend's `dbuild`. How big is it? It’s 3.2 million lines of Scala code, total, from 185 projects (as of January, 2019), and takes about 15 hours to run.”

“Why do this? The main goal is to guard against regressions in new versions of Scala (language, standard library, and modules). It’s also a service to the open source community, providing early notice of issues and incompatibilities.”

ScalaCheck custom generator examples

Table of Contents1 - Custom generators2 - Built-in ScalaCheck generators3 - How to use ScalaCheck generators4 - More ScalaCheck generators

Writing custom generators for ScalaCheck can be one of the more difficult and/or time-consuming parts of using it. As a result I thought I’d start putting together a list of generators that I have written or seen elsewhere. Unfortunately I can’t credit all the ones I’ve seen in other places because I google’d and copied them many moons ago, but I’ll give credit/attribution to all the ones I can.

Back to top

Custom generators

This is a combination of generators I wrote, and some that I copied from other places and may have modified a little:

JMH, an SBT plugin for running OpenJDK JMH benchmarks

JMH is an SBT plugin for running OpenJDK JMH benchmarks. Per its docs, “JMH is a Java harness for building, running, and analysing nano/micro/milli/macro benchmarks written in Java and other languages targeting the JVM.”

They also recommend reading an article titled Nanotrusting the Nanotime if you’re interested in writing your own benchmark tests.