Category: Tools for Testing

Getting Started with Ruby and rbenv on a Raspberry Pi

Note To Self Ruby Tools for Testing Uncategorized No Comments

In preparation of a workshop at Agile Testing Days 2022, I’m setting up a Raspberry Pi as a backup system for participants, to be prepared if things go wrong. Especially one of the first steps “Installing Ruby – If Necessary” has the potential to fail or take too long.

With the keyboard configured (see the previous post “Setting Up a Raspberry PI with a German Mac Keyboard“), the next step is installing a recent Ruby version. I’ll use rbenv , a widespread tool to manage Ruby versions on a machine.

Installing rbenv

The rbenv page suggests to install the tool using a basic git checkout.

~ $ git clone https://github.com/rbenv/rbenv.git ~/.rbenv
Cloning into '/home/guest/.rbenv'...
remote: Enumerating objects: 3138, done.
remote: Counting objects: 100% (288/288), done.
remote: Compressing objects: 100% (147/147), done.
remote: Total 3138 (delta 165), reused 231 (delta 131), pack-reused 2850
Receiving objects: 100% (3138/3138), 626.69 KiB | 3.12 MiB/s, done.
Resolving deltas: 100% (1955/1955), done.

Following the next step in the docs, .bashrc is updated to initialise rbenv:

~ $ echo 'eval "$(~/.rbenv/bin/rbenv init - bash)"' >> ~/.bashrc

Restarting the terminal app actually loads the updated .bashrc, and then rbenv is installed and configured.

Another step is to also install the ruby-build plugin, which rbenv uses to compile and install new Ruby versions. I’ll use git to clone this plugin and upgrade it (as documented in https://github.com/rbenv/ruby-build#readme):

~ $ git clone https://github.com/rbenv/ruby-build.git "$(rbenv root)"/plugins/ruby-build

Now, rbenv can be used to install Rubyies:

~ $ time rbenv install 3.1.2
To follow progress, use 'tail -f /tmp/ruby-build.20221110172124.19039.log' or pass --verbose
No system openssl version was found, ensure openssl headers are installed (https://github.com/rbenv/ruby-build/wiki#suggested-build-environment)
Downloading openssl-3.0.7.tar.gz...
︙

As a last step set this new Ruby version to be used globally:

rbenv global 3.1.2

That’s it. Ruby 3.1.2 is now available for the user an the Raspberry Pi.

Monitoring Tomcat

Tools for Testing No Comments

Recently, I faced an issue with an application which is deployed in a Tomcat web container: In one of the environments it started to consume a lot of CPU cycles and memory.

My first attempt to investigate, is to run things locally and have a look at the Activity Monitor that comes with macOS. Often enough it’s enough to notice which app uses a lot of memory or CPU cycles.

This time though, I wanted some deeper insight and I already knew what I was looking for. Some searching in the net brought up Glowroot.

Even though I’m not experienced in using Tomcat, it was pleasantly easy and quick to get going:

  • Download a zip file and unpack it.
  • Copy the folder to a place where it’s convenient. I copied it into an existing folder I’m using to keep configuration info for Tomcat anyway.
  • Set up a way for Tomcat to find and use the Glowroot jar file.
  • Start Tomcat
  • Open a Browser at http://localhost:4000

The details for these steps are nicely explained on the GitHub Wiki of this project.

An example graph is this, taken from the projects demo site at https://demo.glowroot.org/

The my project this (so far) only confirmed that memory consumption can increase a lot when the system gets some traffic. Using well over 10GB of memory within a few minutes is a lot, especially when that memory isn’t released any time soon.

Are you using a tool that was particularly easy to use and provided what you were looking for? Which one?

Seeing And Saying On The Command Line

Note To Self Tools for Testing No Comments

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 >(say&)

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:

curl -s -u <username:thepassword> “<url_to_locally_running_service>” | jq “<path_to_version_info_in_json>” | tee >(say&)

The GitHub page explains that

jq is a lightweight and flexible command-line JSON processor.

https://stedolan.github.io/jq/

It’s well worth trying, if you’re dealing with JSON input on the command line.

After Updating to macOS 11.0 Big Sur

Testing Tools for Testing Uncategorized No Comments

The Context

In my current project, we’re using Apache Tomat and Eclipse as the IDE. The Java Platform is Amazon Corretto 11. I’m using macOS and the working setup before upgrading was this:

  • 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!

The Solution

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!

The documentation has a section about this (docs can be so useful!):

(3.2) Set JRE_HOME or JAVA_HOME (required)

These variables are used to specify location of a Java Runtime
Environment or of a Java Development Kit that is used to start Tomcat.

The JRE_HOME variable is used to specify location of a JRE. The JAVA_HOME
variable is used to specify location of a JDK.

Using JAVA_HOME provides access to certain additional startup options that
are not allowed when JRE_HOME is used.

If both JRE_HOME and JAVA_HOME are specified, JRE_HOME is used.

The recommended place to specify these variables is a “setenv” script. See
below.

…/tomcat/9.0.39/libexec/webapps/docs/RUNNING.txt in my Tomcat installation

Furthermore, there are comments explaining what to expect with respect to JAVA_HOME & JRE_HOME in catalina.sh:

# JRE_HOME Must point at your Java Runtime installation.
# Defaults to JAVA_HOME if empty. If JRE_HOME and JAVA_HOME
# are both set, JRE_HOME is used.

…/9.0.39/libexec/bin/catalina.sh. lns 61 ff

It’s still not entirely clear what caused this behaviour.
If you have an idea or ran into a similar problem, I’d definitely like to known about it.

Agile Testing Days 2020 – the Other Two Days

Conferences Learning Tools for Testing 1 Comment

In a previous post I summarised the 1st day of the Agile Testing Days 2020.

Lean Coffee

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:

  1. 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.
  2. 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.
  3. Automated accessibility testing
    At least some parts of accessibility (commonly abbreviated a11y) testing can be automated. More on that later.
  4. 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:

Automated Accessibility Testing

I participated in Cecilie Haugstvedt‘s workshop ‘Automatic Accessibility Testing for All‘.

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:

Thank you Mariia for the wonderful summary!

Do you also have insights and ideas you took home (where you probably were all the time anyway, this year)? What are they?

© 2012-2023 Stephan Kämper — Mastodon

MENU

Navigation

%d bloggers like this: