Joep Schuurkes (Posts about programming & test automation)

Benchmarking counterstring implementations in TypeScript

Joep Schuurkes — Sat, 22 Feb 2025 23:00:00 GMT

Earlier this year I posted about how I implemented a counterstring function using "fake it till you make it". I also posted about different ways to implement counterstrings. In this post, I want to share how those different implementations compare performance-wise.

To do this, I used both Tinybench and vitest bench (which uses Tinybench). The results are basically the same, but their default output is slightly different.

The nine implementations

Before I present the results, I should describe the different implementations and how they differ from each other. The actual code of each implementation is available on Codeberg. Here I'll only mention what makes each implementation interesting compared to the others:

Comparing counterstring implementations in TypeScript

Joep Schuurkes — Sat, 18 Jan 2025 23:00:00 GMT

In my previous post "Using 'fake it till you make it' to implement counterstring" I mentioned the implementation I included there, wasn't my initial implementation:

I did something less performant with reversing an array, because I had looked at PerlClips's source code. How that came about and what I learned from it, is for another blog post.

This is that blog post.

As a matter of fact, I currently have 9 different implementations of counterstring in TypeScript. Including two that are not mine: one is from PerClip but translated to TypeScript by me, the other is EvilTester's implementation. There are some interesting lessons to take, both from comparing the code of the different implementations, as from comparing the differences in performance. The performance-part of the comparison will have to wait for my next post, though.

Using "fake it till you make it" to implement counterstring

Joep Schuurkes — Sat, 04 Jan 2025 23:00:00 GMT

Last week I implemented PerlClip's counterstring in TypeScript. A counterstring is a string that tells you how long it is. For example a counterstring with length 9 looks like this: *3*5*7*9*. Each number tells you the position of the asterisk following the number. My main goal with this project is to learn more about front-end development.

Before I could start doing any front-end stuff, however, I needed to write a function that correctly generates counterstrings. Since I approached it in a way that I really enjoyed, inspired by Llewellyn Falco "Fake it till you make it", I figured it would make a good first post about this project.

The idea behind "fake it till you make it" is simple. Start with an implementation covering a single case ("fake it") and then pull it apart little-by-little until it becomes an actual program ("make it"). As Llewellyn explains in the video, the value of this technique is that it's a lot easier to start from a working example and proceed from there than it is to get complete requirements.

I did approach counterstring from the opposite direction, though, as Llewellyn did with Fizzbuzz in the video. Llewellyn starts with FizzBuzz length 20, so a case covering all the logic. Then he refactors it using different techniques, such as separation and encapsulation. While I started with counterstring length 0, the most simple case, and then worked my way up to larger lengths.

What do you fix when you fix a test?

Joep Schuurkes — Sat, 24 Aug 2024 22:00:00 GMT

You ran the tests¹ - or a pipeline did it for you - and some of them failed. Time to fix the tests! But what is it exactly that needs fixing?

There are quite a few things that might make a test fail:

an issue with the build
an issue with the pipeline (if that's where the test runs)
an issue in the environment the code under test is running on
an issue in the environment the test code is running on
a bug in the code under test
a mistake in the test code
a mistake in what the test should test

Arguably, on the last three describe a test that fails. The test did its job detecting a problem. In the first four we didn't even get that far. The issues prevented the test from doing its job. So in those cases, it's not the test(s) as such that need fixing.

Tackling test automation in a new language

Joep Schuurkes — Sat, 10 Feb 2024 23:00:00 GMT

While there's value in learning all the ins-and-outs of one particular language, its ecosystem and its testing libraries, I think there's also a lot of value in having experience in several. Or at least, in two. If you only know one, you don't really know what's essential and what's incidental to the one set of tools you know. You don't know from experience in what ways things could be different.

Picking up a new language is not trivial though, especially if it's your second one. There will be a lot to learn. You will notice similarities between the new language and the one(s) you already know. Sometimes those similarities will help you, sometimes they will mislead you.

Also, it's more than picking up a new language. There are also the testing libraries you will use and the language's ecosystem (e.g. how to install those libraries¹ or how to set up a pre-commit hook with a linter). That's quite a package.

A lesson from every language I've used

Joep Schuurkes — Thu, 28 Dec 2023 23:00:00 GMT

Throughout the years I've used quite a few different languages - if you allow me to be somewhat generous with the word "use". One language I actually feel proficient in. Some languages I've only done coding exercises in. And one language I've only used for a total of maybe 10 minutes, but that did really help out a whole team.

I do believe we should be that generous, both towards ourselves and to others. For an industry that likes to talk about imposter syndrome, we seem to enjoy saying "You're not a real ... unless..." a bit too much.

Listing these languages for myself made me wonder what I had learned from them. Did I just learn how to write some code in each of them? Or did I also pick up some more general lessons? Turns out I did.

Getting [name] from "Name: [name]" in Python - an engineering problem

Joep Schuurkes — Mon, 26 Aug 2019 19:27:38 GMT

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.

How this tester writes code

Joep Schuurkes — Sat, 08 Jun 2019 16:21:38 GMT

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.

Test automation - five questions leading to five heuristics

Joep Schuurkes — Tue, 24 Mar 2015 19:53:24 GMT

I wrote a follow-up to this post in June 2019 in which I revisit the heuristics from this post.

In 1984 Abelson and Sussman said in the Preface to 'Structure and Interpretation of Computer Programs':

Our design of this introductory computer-science subject reflects two major concerns. First, we want to establish the idea that a computer language is not just a way of getting a computer to perform operations but rather that it is a novel formal medium for expressing ideas about methodology. Thus, programs must be written for people to read, and only incidentally for machines to execute. Second, we believe that the essential material to be addressed by a subject at this level is not the syntax of particular programming-language constructs, nor clever algorithms for computing particular functions efficiently, nor even the mathematical analysis of algorithms and the foundations of computing, but rather the techniques used to control the intellectual complexity of large software systems. [emphasis mine]

This oft-quoted sentence I emphasized, is even more true if the purpose of our programs is test automation¹. So let's say you run your test automation program and the result is a list of passes and fails. The purpose of testing is to produce information. You could say that this list of results qualifies as information and I would disagree. I would say it is data, data in need of interpretation. When we attempt this interpretation, we should consider the following five questions.

Lessons learned in some test automation

Joep Schuurkes — Mon, 18 Feb 2013 20:46:02 GMT

In the past two weeks I built a test tool in VBA (Visual Basic for Applications). I did this, because two weeks ago my fellow tester showed me an important test we have to do at least once for each major release. The test consists of having the application generate three reports in Excel format. On two of these reports you apply a set of filters and take the sum of a few columns, rinse and repeat. Then you add several of those sums together and the results of those calculations should match the numbers in the third report. So basically, the point of the test is to check if the numbers in the three reports add up. And it's a lot of work, i.e. about two days.

After being shown how to perform the test, the first thought that popped into my head, was: "Boring!" The second thought was: "It's automatable!" And since there was little else to do - delivery of the new test environments was delayed - I changed it from automatable to automated.

So now, after two weeks, I have this tool in VBA. For each of the three reports it contains a sheet in which you define the sets of filters and sums. If you click a big button, the report is opened and the filters and sums are applied. There's also a fourth sheet to do the second set of calculations and to do the check if the numbers match. This last part is not done in VBA; it's all formulas in Excel.