Category: Tools for Testing

Docker’s ‘docker stats’ & names

This is mostly a technical reminder to my future self and a selection of the tips from a proposal I found at https://github.com/moby/moby/issues/20973. 😉

When using Docker, now and then I need to keep an eye on the run-time behaviour of the Docker containers. To do this, there’s a nice docker command:

docker stats

How ever, in the current version (17.05.0-ce, build 89658be), the containers are listed using the container ID.

I find it much easier to use the container names instead of the IDs, so here are two ways to display them:

  1. On an environment I don’t control (a colleagues machine when pairing, a test environment…) there’s a way to change the display of ‘docker stats’ for a single use of the command:
    docker stats $(docker ps --format={{.Names}})
  2. On my machine, I like to have this all the time, so I edited ~/.docker/config.json and added the following key-value pair:
    "statsFormat": "table {{.Name}}\t \
    {{.CPUPerc}}\t \
    {{.MemUsage}}\t \
    {{.MemPerc}}\t{{.NetIO}}\t \
    {{.BlockIO}}\t{{.PIDs}}"

    (The backslash at the end of the line indicates the the line is actually continuing.)

Announcement: Workshop & ebook: “Fast Feedback Using Ruby”

At the “London Tester Gathering Workshops 2015” (also see #LTGWorkshops on Twitter) I offer a workshop “Fast Feedback Loops & Fun with Ruby”. For this, I wanted to give attendees a handout, to make applying the stuff covered easier and it was planned to be a list of brief recipes.
Suffice to say that the handout grew (and it’s entirely possible that this is ‘feature creep’ in action). In fact, it grew to the point that I decided to turn it into an ebook. The book is not done yet, there’s some copy editing to do.

Fast Feedback Using Ruby

In any case: There will be an ebook, and it will be available on LeanPub at https://leanpub.com/fastfeedbackusingruby/. If you’re interested, please leave a note on the book’s pages.

London Tester Gathering Workshops 2015: Early News

There’s news about the London Tester Gathering Workshops 2015: I’ll offer one of the workshops!

I’m sure we’ll have a couple of exiting days talking about software testing. And not only talking but also some hands-on stuff using Ruby for fun and (fast) feedback.

Before I publish more information about my workshop, I’d like it to…

look right

Stay tuned!

The Agile Testing Days 2014 – Day 1: The Tutorial

The 1st day of the Agile Testing Days for me was a full-day tutorial by Alan ‘The Evil Tester’ Richardson about technical testing. The tutorial was very hands on, and we actually tested something — a website.

I liked how we started with the website as such and focused on the relatively simple aspects of getting a user account and logging in. We did some testing and then reflected on what we were doing and how we did it. For example there were various ways of note-taking:

  • I mostly used pen & paper, and for some notes a text editor (e.g. when I knew that I would like to make a note of text I would enter more than once)
  • Some used their text editor of choice, Evernote or similar tools.

After interacting with the application ‘just’ using the basic browser feature of rendering HTML, we stepped down to a slightly deeper technical level and used ‘developer tools’. These allow interaction with the DOM and, for example, manipulate what an HTML form would submit back to the server — including, but not limited to, selected values of drop down lists. — While not every user will do that, some will. And it’s a good idea to test that your server can candle this unexpected input. We also looked into a number of tools to capture (and again manipulate) network traffic, such as HTTP proxies.

I liked how ‘technical testing’ was presented as something that is different from ‘test automation’. Many of the tools we use for testing enhance our possibilities as testers — and sometimes they also allow for some automation. The main point of technical testing though, is increasing the testers reach into the technical details of the system under test.

This is what I expected from the day and also what was delivered in the tutorial.

Thank you Alan, I liked it a lot!

Tools for Testing — 2

Just like the first tool for testing ‘GraphViz’ I briefly described earlier, today’s tool is not limited to be used in testing.

In most of my projects, I use the command line a lot. My colleague Marcus Franke pointed me to autojump, which allows you to quickly navigate directory structures, as well as open folders in a GUI tool like the Finder (or Pathfinder) on a Mac (and I’m sure it works similarly on Windows & Linux).

As the project page says:

autojump is a faster way to navigate your filesystem. It works by maintaining a database of the directories you use the most from the command line.

I use a Mac (most of the time) as well as Homebrew, so the installation of autojump was simple:

brew install autojump

After using cd to navigate to my most visited directories to ‘train’ auto jump, I can use ‘j d’ to jump into my dev folder, which is where I keep all my project directories:

$ j d
/Users/stephan/dev
~/dev $

Yes, it’s just three key strokes: ‘j’, space and ‘d’. I like this quick way to jump between directories, because it’s a lot less typing (compared to entering the real path names) and moving back and forth in the directory structure is pretty easy and fast.