Quis experiet ipsas experientiae?

Who will test those tests?

A while ago I was invited by the lynch-mob in #twisted to write a post about what I meant when I said that "Unit tests are not real tests", and here it is.

Now, recently there has been much said about Unit-testing, and code coverage, and even sensationalist blog post titles, which in retrospect "Unit tests are not real tests" would have been. I won't talk about code test coverage here, because its not relevant, we should strive to get as much coverage as we can. And of course I believe that unit tests are a fundamentally important piece of development. Especially since I tend to use Python, which is prone to disaster if not tested correctly.

So, if unit tests are real tests, then why did I say they aren't? I deal mostly with application development. The user of the application is a human being. Now quite simply, the only true test of my application is the user interacting with it. I understand now that this is not really the case for library development, where the user is a piece of code, and I guess you can have true tests for it that are unit tests.

So how do we do it? Well, I am not sure what kind of testing this is, but I call it "Acceptance Testing". It is evidence that the application behaves as advertised. I guess it would come under headings like "Verification". We have a list of written tests that go something like:

TestExpected OutcomeActual Outcome
User double-clicks the iconlog in screen displayed
User enters date in the futuretext entry goes red and user is informed


And they go on and on, we have hundreds of pages of these. As I was in a start-up consisting of one person, I used to do these myself. Now the test department does it.

But these tests are just another type of unit test! Yes they are, and probably purists would disagree, but look at them:

  • You test every single unit of an application (but from the user perspective)
  • When you find a bug, you write a new test to test for it, then fix it
  • When you add a new feature, you write the tests first (TDD!)
  • Anyone can run the tests
And then as an added bonus you can give them to the client to run, which some of our clients insist on. They differ from traditional acceptance tests as they are run on single acceptance from the client.

Can't you automate these? Yes you can, but that would again slip them into the realms of "non-real tests". As I said, a human user has to test the application in order to reflect the actual user of the software. I really love automation. I have hacked on kiwi's automated test-runner, played with various other tools. Again, like traditional code-based unit tests, they are great tools.

So, I should really amend my statement to the #twisted guys to something more like:

"Code-based unit tests are not the true tests for an application that interacts with a human user."

Popular posts from this blog

PyGTK, Py2exe, and Inno setup for single-file Windows installers

I am lucky, as part of my job, I get to code PyGTK. The downside is of course that I have to deploy these applications on Windows. Now these Windows users (especially at the price they are paying for this stuff) don't install dependencies, don't understand what a scripting language or interpreter is, and frankly they should not have to. Unfortunately, the list of dependencies for a PyGTK application (at the very minimum) is Python, GTK, PyGTK, PyGObject, PyCairo. 5 installers! So very early on in this project I found the way to give them exactly what they want and deserve, a single-file executable installer. There are a few guides online about how to achieve this, but none seem to work, and none are particularly new. How do we achieve this? The toolchain involved consists of two elements: 1. Py2exe website 2. Inno Setup website NOTE: The documentation for all the tools used is extensive, I will not repeat everything in there. Py2exe Py2exe is a distutils extension that searches
Read more

ESP-IDF for Arduino Users, Tutorials Part 2: Delay

This is the second part of a series of ESP-IDF tutorials that I will complete as I learn stuff. Read part 1. One of the best things about Arduino is the ability to just block for a period with: delay(1000); // hang on a second, buddy It’s also one of the worst things. As soon as you need to do a few things at the same time, you will end up using better systems, like calling millis() or using the elapsedMillis library. Anyway, the IDF has you covered. You can delay, but amazingly it appears that once you multi-task (which you will with Free RTOS), the delay doesn’t block the other tasks from running. My Notes: Read the docs, now or later https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/system/freertos.html Delay doesn’t have to block like Arduino. Delay some milliseconds like this: vTaskDelay(pdMS_TO_TICKS(10)); Since vTaskDelay accepts ticks, the pdMS_TO_TICKS macro will convert for you. Help yourself out by adding your own macros if you are lazy. I am lazy. #
Read more

How to install IronPython2 with Mono on Ubuntu

This is just an instructional post with the hope that it might help others in the future. I spent a long time trying to get IronPython2 running on Mono. Now IronPython1 ships with Ubuntu, so apt-get install ironpython , if that's all that you want. Ironically, I don't really know the difference between IronPython1 and IronPython2, but "2 has got to be better than 1", right? The good news is that its very possible, but you will have to step out of your comfort zones. You will need: Mono 2.4 (sources) and IronPython 2.0.1 (binary) First build Mono (note that you need Ubuntu's Mono to bootstrap, so apt-get install mono ) but make sure you put it somewhere special so it doesn't mess with the system-installed Mono. This advice is taken from an article on the Mono wiki . $ tar xvjf mono-2.4.tar.bz2 $ cd mono $ mkdir -p ~/opt/mono $ ./configure --prefix=~/opt/mono $ make && make install So this is putting Mono in opt/mono in my home directory (which is wher
Read more