If for some reason you ever need a list of people’s given names for testing your Java/Scala/Kotlin/JVM code, here’s a Java class with a sorted, static list of over 5,000 male and female given (first) names:
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.
Kent Beck has a good article on Medium titled, Programmer Test Principles.
“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)
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.
This Wikipedia page on continuous integration is actually a good resource for computer programming best practices.
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.”
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
This is a combination of generators I wrote, and some that I copied from other places and may have modified a little:
If you ever need to intentionally throw and catch an exception with ScalaTest, here’s an example of how to do that:
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.