Early in chapter 3 of the Brave and True-book the Boolean operators and and or are introduced:

Clojure uses the Boolean operators or and and. or returns either the first truthy value or the last value. and returns the first falsey value or, if no values are falsey, the last truthy value.

This explanation is followed by some examples:

(or false nil :large_I_mean_venti :why_cant_I_just_say_large)
; => :large_I_mean_venti

(or (= 0 1) (= "yes" "no"))
; => false

(or nil)
; => nil

(and :free_wifi :hot_coffee)
; => :hot_coffee

(and :feelin_super_cool nil false)
; => nil

What I found remarkable about this is that and and or do not return a boolean in all cases. Before I go into that, let’s back up a second and cover their basics in a little more depth first.

Read more…

As mentioned in my previous post I’ve decided to use Vim as my Clojure editor. That leaves me with three things to do: getting reacquainted with Vim, updating my Vim config in the .vimrc file, and installing both general and Clojure-specific Vim plugins.

Getting reacquainted with Vim

Ever since I learned Vim basics a long time ago I have been using it once in a while to make small edits to a config file or a commit message, but not for anything more complicated than that. So that’s the first thing I wanted to address: refresh my basics and make sure I know where to find more information when I need it.

Vimtutor

I figured that a good way to get back into Vim was the Vimtutor. It’s a 30-minute interactive tutorial where you edit a file with instructions with vim. I kept notes of what it covers, which you can find here. Vim’s help also includes a quickref, an “Overview of the most common commands you will use”, which is intimidatingly long considering that description. As a reference to look things up in, it should be useful, though.

Read more…

The second chapter of “Clojure for the Brave and True” is all about Emacs, “an excellent Clojure editor”. Now you might wonder: does your choice of editor really matter that much? You’re learning the language, so you don’t need advanced IDE features. Some syntax highlighting, some code completion, something to help you manage all those parantheses perhaps, done. That would be true if not for the Clojure REPL.

The Clojure REPL

The REPL is definitely a Thing™️ in Clojure. It gives you a prompt where you can type code and it will execute it immediately. You can also load files with code into it, interacting with the functions and data defined in those. So that’s a signifcantly faster feedback loop than having to compile and then run - which is how you’d normally run something written in Clojure, since its primary platform is the JVM. There are different ways of launching a REPL, but most guides I found tell you to use Leiningen. Oh, and REPL stands for Read-Evaluate-Print_Loop, because that’s what the REPL does.

It definitely feels like this REPL is a bigger deal than I appreciate right now. Probably because I have only just begun learning Clojure. On the other hand, I may have also been spoiled by the quick feedback provided by Python and its IDLE. On the third hand, it’s only because of learning of the Clojure REPL, I looked into importing files into Python’s IDLE and found out that’s indeed a thing it can do.

Read more…

Why Clojure?

A long time ago (meaning I don’t remember when but it’s been a while) I learned about a programming language called Lisp. It was said that by studying this language you’d gain deep insights into programming and you’d never write code the same way again. That definitely piqued my interest.

Some time later (don’t remember when exactly either) I learned about the existence of Clojure and that it too, was something special. So I added it to the list of programming languages I wanted to learn some day.

Then, earlier this month, I felt the need to start a new project. To learn something new. So I figured I’d learn Lisp. That didn’t last long though, as I found out that the recommended editor for Lisp is Emacs. And from trying out Emacs and vi about 20 years ago I knew that for some reason vi does fit with how my mind works, and Emacs doesn’t.

Read more…

Today I was presented with an interesting engineering problem. (Important later: context was the code of an auto-test.) Given a string of the format “Name: [name]”, what’s the best way to get the [name] in Python?

There are several options:

• lstrip()
• split()
• replace()
• string slicing
• regex

So let’s look at each of them and then I’ll explain which one I prefer and why. All examples are in Python 3.6, using the Python Interpreter.

Read more…

CI/CD pipelines

The purpose of a CI/CD pipeline is to allow you to deliver small changes in a fast and controlled way. Without any tests in your pipeline you would gain a lot of speed. You’d also lose a lot control, which is why people in general do run tests in their pipeline. The purpose of these tests is to check if that stage of the pipeline meets the minimum level of acceptable quality for that stage.

For example, commit stage tests will consist of mostly unit tests, a few integration tests, and even fewer end-to-end tests, because early in the pipeline speed is more important than comprehensiveness. When I commit my changes, I want the results fast enough so that I will wait for them - ready to fix any issue that might occur.

Regression testing

There are many definitions of regression testing, as you can read in Arborosa’s blog post on the topic. I have always defined regression testing along the lines of “testing the parts that weren’t impacted by a change to see if they really weren’t impacted.” (Which is really weird if you start thinking about it: something is regression testing depending on your knowledge of the system and the change.)

The tests in your pipeline are regression tests, …

Most of the tests that run in your pipeline are regression tests. Your commits are small and you have a lot of tests, so most of those will cover parts of the system that shouldn’t have been impacted by your changes. So yes, regression tests.

Read more…

A long time ago (March 2015) I wrote a post titled “Test automation - five questions leading to five heuristics”. Later that year Rich Rogers asked for a follow-up. To which I replied I should do a follow-up post (ahum) “soon”. Then last Wednesday Noah Sussman said on twitter: ‘I don’t know that I’ve *ever* seen “this is how testers write code”’. To which I replied “challenge accepted”, so now here we are, me writing a blog post about how I as a tester write code.

The format of this post turned out to be advice based on my experiences, so the usual disclaimers apply. And feel free to leave a comment if you have any feedback!

The basics

use an IDE

An IDE is not just an advanced text editor. It understands your code - to a degree, since it’s not interpreting, compiling or executing the code. So not only allows an IDE you to manipulate your code as text, it also allows you to manipulate your code as code.

Read more…

James Lyndsay has created a number of amazing Black Box Puzzles: tiny applications that challenge you to figure out what they do. (You can support him in creating more of these at his Patreon page.) Two of these Puzzles, 29 and 31, not only have a GUI to explore, but also an API.

And that gave me an idea. If you explore these Puzzles through their GUI, you start from the inputs. You try out different inputs in the hope of discovering a pattern in the outputs. And then that pattern feeds back into your exploration.
With an API, however - and because of the nature of Puzzle 31 - it becomes easy to get the outputs for all possible combinations of inputs. Which means you can start your exploration from the outputs instead of the inputs.

Before I tell you how and what I did, three important remarks.
First of all, I will be spoiling the solution to the Puzzle in this blog post. So this is the right moment to go and solve Puzzle 31 for yourself first. Or at least go play a bit with it, so you have an idea what the inputs and outputs are.
Secondly, I had already solved the Puzzle through the GUI a few months ago. So it was more of a “Can I find the solution this way as well?” than a “Can I find the solution?” thing.
Finally, the code and the spreadsheet I created (linked throughout, also available on GitHub here), are not very clean. I thought about tidying them up, but my two reasons for not doing so are (1) laziness; (2) the way they are now gives a more honest picture of what I did.

Read more…

I originally wrote this primer to share with people at work. The first section is intended to be generally applicable; the second not necessarily so. The main influences on this primer are:
- Rapid Software Testing’s Heuristic Test Strategy Model
- James Lyndsay’s Why Exploration has a place in any Strategy
- Rikard Edgren’s Little Black Book on Test Design

This document contains two sections:

• Why have a test strategy? - what is a test strategy and what’s its purpose
• Test strategy checklist - checklist for describing your test strategy

Why have a test strategy?

The purpose of a test strategy is to answer the question: “How do we know that what we are building, is good enough?” As such, every team has a test strategy, even if it’s only implicitly defined through the actions of the team members.

Read more…

Earlier this month I published my Manifesto for software testing. This manifesto is my attempt to bring together what I have learned about testing from the context-driven, agile and DevOps communities. Below you can find the manifesto with my reflections on it.

1. Testing is investigating in order to evaluate a product.

This definition is clearly influenced by James Bach’s “questioning a product in order to evaluate it”. I’m not sure at which point I started misremembering his definition as “investigating a product…”, but it works well with a change I did make intentionally: moving “a product” to the second part of the definition. As explained in 6. I believe that in order to evaluate the product, we need to investigate a number of different things, not only the product.

Read more…