Tag Archives: unit testing

Work

January 2024 month notes

Water CSS

I started giving this minimal element template a go after years of using various versions of Bootstrap. It is substantially lighter in terms of the components it offers with probably the navigation bar being the one component that I definitely miss. The basic forms and typography are proving fine for prototyping basic applications though.

Node test runner

Node now has a default test runner and testing framework. I’ve been eager to give it a go as I’ve heard that it is both fast and lightweight, avoiding the need to select and include libraries for testing, mocking and assertions. I got the chance to introduce it in a project that didn’t have any tests and I thought it was pretty good although it’s default text output felt a little unusual and the alternative dot notation might be a bit more familiar.

It’s interesting to see that the basic unit of testing is the assertion, something is shares with Go. It also doesn’t support parameterised tests which again is like Go which has a pattern of table-driven tests implemented with for loops except that Go allows more control of the dynamic test case naming.

I’d previously moved to the Ava library and I’m not sure there is a good reason not to use the built-in alternative.

Flask blueprints

In my personal projects I’ve tended to use quite a few cut and paste modules and over the years they tend to drift and get out of sync so I’ve been making a conscious effort to learn about and start adopting Flask Blueprints. Ultimately I want to try and turn these into personal module dependencies that I can update once and use in all the projects. For the moment though it is interesting how the blueprints format is pushing me to do some things like logging better (to understand what is happening in the blueprint) and also structuring the different areas of the application so that they are quite close to Django apps with various pieces of functionality now starting to be associated with a url prefix that makes it a bit easier to create middleware that is registered as part of the Blueprint rather than relying on imports and decorators.

Web components

I’ve been making a bit of progress with learning about web components. I realised that I was trying to do too much initially which is why they were proving complicated. Breaking things down a bit has helped with an initial focus on event listeners within the component. I’m also not bringing in external libraries at the moment but have got as far as breaking things up into [ESM modules](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules) which has mostly worked out so far.

Standard
Programming

Refactoring abuse and strong type compiler systems

“Refactoring” is one of the most abused terms in programming. It has a formal meaning but when generally used it tends to mean rewriting or restructuring code (or as I like to refer to it: changing stuff). One interesting new use of refactoring I heard recently was to describe extracting common code. Creating some new codebase is perhaps the opposite of refactoring.

So refactoring tends to mean developers are just changing things they have already written. Real refactoring is of course done to code under test so I was interested in a Stuart Halloway quote about compilation being the weakest form of unit-testing. Scala is used a lot at the Guardian and it has a more powerful type system and compiler than Java which means if you play along with the type system you actually get a lot of that weak unit-testing. In fact structuring your code to maximise the compiler guarantees and adding the various assertion methods to make sure that you fail fast at runtime are two of things that help increase your productivity with Scala.

If you’ve seen the Coursera Scala videos you can see Martin Odersky doing some of this “weak refactoring” in his example code where he simplifies chained collection operations by moving or creating simple functionality in his types.

Of course just like regular refactoring there have to be a few rules to this. Firstly weak refactoring absolutely requires you use explicit function type declarations. Essentially in a weak refactor what you are doing is changing the body of a function while retaining its parameters and return type. If you can still compile after you’ve changed code you are probably good.

However the other critical thing is how much covariance the return type has. A return type of Option for example is probably a bad candidate for weak refactoring as it is probably critical whether your changed code still returns Some or None for a given set of a parameters. Only conventional refactoring can determine whether that is true.

Standard
Groovy, Java, Programming, Scripting, Software

Working with Groovy Tests

For my new project Xapper I decided to try and write my tests in Groovy. Previously I had used Groovy scripts to generate data for Java tests but I was curious as to whether it would be easier to write the entire test in Groovy instead of Java.

Overall the experience was a qualified “yes”. When I was initially working with the tests it was possible to invoke them within Eclipse via the GUnit Runner. Trying again with the more recent 1.5.7 plugin, the runner now seems to be the JUnit4 one and it says that it sees no tests, to paraphrase a famous admiral. Without being able to use the runner I ended up running the entire suite via Gant, which was less than ideal, because there is a certain amount of spin-up time compared to using something like RSpec’s spec runner.

I would really like all the major IDEs to get smarter about mixing different languages in the same project. At the moment I think Eclipse is the closest to getting this to work. NetBeans and Intellij have good stories around this but it seems to me to be a real pain to get it working in practice. I want to be able to use Groovy and Java in the same project without having Groovy classes be one of the “final products”. NetBeans use of pre-canned Ant files to build projects is a real pain here.

Despite the pain of running them though I think writing the tests in Groovy is a fantastic idea. It really brought it home to me, how much ceremony there is in conventional Java unit test writing. I felt like my tests improved when I could forget about the type of a result and just assert things about the result.

Since I tend to do TDD it was great to have the test run without having to satisfy the compiler’s demand that methods and classes be there. Instead I was able to work in a Ruby style of backfilling code to satisfy the runtime errors. Now some may regard this a ridiculous technique but it really does allow you to provide a minimum of code to meet the requirement and it does give you the sense that you are making progress as one error after another is squashed.

So why use Groovy rather than JRuby and RSpec (the world’s most enjoyable specification framework)? Well the answer lies in the fact that Groovy is really meant to work with Java. Ruby is a great language and JRuby is a great implementation but Groovy does a better job of dealing with things like annotations and making the most of your existing test libraries.

You also don’t have the same issue of context-switching between different languages. Both Groovy and Scala are similar enough to Java that you can work with them and Java without losing your flow. In Ruby, even simple things like puts versus println can throw you off. Groovy was created to do exactly this kind of job.

If the IDE integration can be sorted out then I don’t see any reason why we should write tests in Java anymore.

Standard
Java, Programming

Shtop! You’re copying the wrong JUnit!

I have been using JUnit 4.4 on my most recent project and this time instead of just licking around the edges I have actually being trying to use the features it adds. This time I have actually switched from using assertX to just using assertThat in combination with the various Hamcrest matchers.

I have also been using the Datapoint and Theory functionality for a mix of empirical testing (putting through a set of data that has proven problematic in the past) and also for creating shorter specific tests that tests a class of behaviour.

I haven’t used Assumptions yet but everything new I have touched has turned out to be solid gold. The only obvious lacking feature is something like RSpec’s Pending description, @Ignore is a bit rubbish really.

Therefore when I am looking at other languages (such as Flex’s ActionScript) I am really disappointed when their testing tools is actually a rather literal port of JUnit 3. Porting JUnit 3 is the act of a charlatan. It seems to be about finding the lowest common denominator that would allow you to wave some TDD colours rather than genuinely providing tools that developers need.

During the long hiatus between JUnit3 and JUnit4 was TestNG and in many ways I would rather that people used that as their template for a testing library. My current gold standard is RSpec though and I am not really seeing anything that ambitious in the “new” languages (except the very lovely Specs).

Often language teams leave library development to the “community” but if you are going to the effort of officially porting something why choose JUnit 3? The only reason I can find is that Java developers are familiar with it and that is just a rubbish reason, Java developers should get out of their comfort zone and move from JUnit 3 to 4 or TestNG. In fact since JUnit 4.5 has just been released this month why don’t you take the chance and plunge in before the month is out?

Standard
Java, Software

Test Blight

Another Bliki entry related post; I’m not sure I would refer to what is described in the article as Test Cancer, I would say it is Test Blight. As soon as one test is switched off it weakens all the other tests and soon the whole “test tree” is dying off as it begins to constrain and describe the system less and less.

Test Cancer is probably a better term for the situation where your test base keeps growing and growing but in a meaningless way that actually obscures what is important in terms of the system description. For example JUnit tests that have no assertions but just execute code. Or hundreds of test files that are testing the accessors of your value objects.

Standard
Java

Build it

This is a brilliant article that I have been using all last month on my work projects and it is both immensely powerful and very practical. It has made testing much easier and saved a phenomenal amount of time. However Nat doesn’t quite explain fully why it is so brilliant. What I have found is that once I have configured a Builder then actually I tend to use the same base object with minor alterations. If I am testing a sales catalogue for example and I want to have a test chocolate bar, then chances are I actually want three or four of them, all pretty much identical except for an id code and name. Using this technique makes it a doodle to knock out several objects in as many lines.

When I started I was conscientious about trying to provide a readable and complete API, later I realised “why bother?”. You need to find some sensible defaults for the necessary fields in the object but once you have you only need to implement the API surrounding the testing you are doing. Once you realise that then you get faster again. A lot of my work involves refactoring an old application and I am constantly surprised how few fields are actually used in the various beans and value objects. Often if you supply the “key” fields (the uid and anything else unique) then nothing else matters.

Standard