Occasionally I like command line tools to also say the output, in addition to ‘printing’ it (to STDOUT).
A current context is starting a server locally with updated information. The start up takes time, so I tend to not wait at the command line for it to fully boot.
I wanted a noticeable signal when the thing is up – and also a confirmation that the version of the information source *is* actually updated. The commands tee and (the macOS) say do this for me:
tee copies the output of its input to STDOUT (usually the terminal) and the given file. The construction >(other command&) causes tee to send the input not to a file but to othercommand and the & causes that command to return immediately (instead of returning only after the command to finish).
Overall, I do something like this. The system returns a lengthy JSON string, so I use jq to get to the version information I’m looking for:
Tomcat is installed using Homebrew: brew install tomcat
Java was installed by downloading the package (see link above) and running the installer.
I have set export JAVA_HOME=/Library/…/amazon-corretto-11.jdk/Contents/Home in .zprofile so the right Java version is used.
I’d start Tomcat from the command line and our tests from inside Eclipse.
This worked nicely.
After The Upgrade
The upgrade went smoothly for most of the software I am using: Other IDEs, installations of Ruby, Elixir, databases, REST clients, git, etc. all continued to work nicely.
The tests however failed in an interesting way: While basic REST calls worked (e.g. a GET request to retrieve version info), the tests that were using the actual functionality were receiving a plain “Internal Server Error” from Tomcat and the application logs showed some getContext method that ended up receiving null instead of the expected object.
Running the same tests on the same machine using the way the tests are started in CI still worked well. The difference between running from within the IDE & the command line: The command line starts Tomcat and runs the tests against that (and then stops Tomcat), while the IDE uses the already running Tomcat. — Aha!
Tomcat logs several environment variables it’s using when it starts, among them JRE_HOME.
And this environment variable pointed to another Java environment, that came from a different source, had a different Java version, and furthermore was (obviously) incompatible with the Java environment set up in JAVA_HOME.
Pointing JRE_HOME to the same Java environment solved the problem and tests are running just fine again. Phew!
2020 was the first year, I facilitated a LeanCoffee. Thank you Janet Gregory & Lisa Crispin for inviting me to help! Since this was an online-only conference, we used a web application and Janet selected LeanCoffeeTable. I found it easy enough to use. I particularly like the ability that all participants can enter actions and learnings during the topic discussions as well as generate a PDF to summarise the meeting. I found this a very pleasant experience.
Here are some of the ideas and insights, I kept:
No Testing Column I’ve learned that some teams entirely remove the testing column(s) from their boards. Obviously, this simplifies the board. But more importantly, it also seems to help teams integrate testing tighter with the overall development. This in turn supports teams working as one entity, and not as a number of people who happen to work on the same story.
After all those years: So many topics about testing Even after years, in some cases decades in testing, there are still areas that one can learn about, drive into and possibly thrive in. The next point is one that surprised me a bit.
Automated accessibility testing At least some parts of accessibility (commonly abbreviated a11y) testing can be automated. More on that later.
Productive ensemble testing Test in an ensemble testing (formerly known as ‘mob testing’, similar to mob programming) can be productive even with people that haven’t worked together. This was mentioned by a Lean Coffee participant who joined a group of people (with whom they never worked with before) for a testing session. To their surprise people worked together quite well.
The Last Talk On Software Testing
I had the great pleasure to moderate Rahul Verma’s talk ‘The Last Talk on SoftwareTesting’, where he explained were he thinks the business of tasting (no typo!) went wrong. Entertaining, hilarious and light hearted. And thankfully not actually the last talk on software testing at all. Here’s a very nice summary by Ekaterina Budnikov:
I was really surprised how far automated testing of accessibility is possible – and how easy it is to get started! In addition to that, I found it interesting that automated a11y (the common abbreviation for accessibility) tests can and should be divided into unit and integration tests.
An important learning: The tests that check contrasts (e.g. of text and background) are integration tests: Most often colours are set site using CSS, so not every article, product description etc. needs to be checked individually. Also the computation of how good (or bad) the contrast is, seems to be more time consuming than I thought it is.
For a first step to get some idea of accessibility of a page in Chrome: Using “CMD-OPTION-I” (on a Mac) or “View ➙ Developer ➙ Developer Tools” (via the menu) open the developer tools. Then go to the ‘Lighthouse’ tab & click generate report.
Moderating a New Voices Track
I also really enjoyed moderating Chris Baumann‘s talk ‘Extreme learning situations as testers’. The talk & topic were so good, some of the attendees stayed in the Jitsi room to discuss the topic for the whole next time slot! The following tweets cover some of the ideas & insights Christian shared with us:
In one of my projects we were faced with a high number of execution paths the system could take. While this is normal and, in fact, expected for all systems these days, in this particular project it was obvious even for the users of the system. The software accepts (interactive) input and then demands more information, as needed in the specific context. There were numerous paths through a network of decisions to get to the point where the final result could be presented to the user.
This is basically describing layers of decisions, leading to various outcomes. To get an overview of the decision tree, I created a diagram using an app (OmniGraffle in this case). The result for one real tree (with abstracted labels) is this:
This isn’t trivial, but it doesn’t look too hard. But then, there are 9 different paths thought the graph. The following image shows each path in one colour:
That’s not as simple anymore. Also note, that the attribute is sometimes updated, leading to different result types (res1 for attribute == 0, res2 for all other cases). It was tedious to create these images to help me see the paths — and fiddling the the arrow to make it look reasonably good, was extra work. To deal with more cases I wanted another approach.
I remembered a tool I had used in a similar situation: GraphViz. It’s the combination of a text format (a graph describing language) and programs to turn this into a graphical representation: images.
Here’s the textual representation of the graph above:
dot is one of the layout programs that comes with GraphViz. With -Ddpi=300 I’ve set the resolution to 300 dpi (to generate a file with a higher resolution than the default). The resulting image file log like this:
While the positioning of the edge labels is not perfect, it happened automatically, as the whole layout of the image. I didn’t have to move things, I could set the styles for all nodes & edges in one place, so that they are guaranteed to look consistent.
In the cases when I used this approach, I could generate the graph description automatically from a (more or less) formal description. In these cases, I could avoid mistakes by ‘hand-drawing’ the graph entirely (well, having tests for the generator code in place… 🙂).
I recently started using Tomcat for a project I’m working on. Since I work on a Mac and am using Homebrew anyway, the installation was as easy:
brew install tomcat
The location of the installed files is /usr/local/Cellar/tomcat on a Mac, BTW. Now, occasionally and out of habit, I run this:
brew update && brew upgrade && brew cleanup
I prefer (usually) small issues with small version jumps to upgrading rarely with bigger version changes (and issues). Also cleaning up seems a good idea, not only on the working desk or kitchen sink.
This time, though, the upgrade removed the previously installed version of Tomcat — including stuff that I had put into a sub folder of the location given above. Not only was the Tomcat installation upgraded, but everything I’ve put in there was gone. 😳
Lesson No. 1: Maybe I shouldn’t have put the stuff there in the first place. Lesson No. 2: Learn how to pin a version of installed software, when using Homebrew.
It’s easy. Use, for example
brew pin tomcat
to, well, pin the tomcat version. To find out later, when you want to upgrade a piece of software and wonder why it does not happen, use
brew list --pinned
to find out, what software is pinned. Last but not least, a package can be unpinned using: