Category Archives: automated tests

The Dark Path?

It always pays to listen to Uncle Bob Martin. He’s clearly someone who’s got something to say. But that doesn’t mean I always agree. Today, I don’t. And I consider it interesting why we disagree.

I’ve just read Robert Martin’s post“The Dark Path”. He picks three innovative traits of Kotlin and Swift: strict null checks, strict exception handling and making classes final (in Java speech) or closed (in Kotlin lingo) by default. It’s an interesting post I recommend to read. Uncle Bob shortly explains these features, continues with complaining about languages becoming too complex because they try to fill each leak of their predecessor languages, and closes with an ardent call to write tests. Like usual, he arguments very convincingly. It’s hard to disagree after reading the article. Yet I do.
Continue reading

Junit 5

When I heard about JUnit 5 this morning, I was baffled. How can you improve something that’s already perfect?

Java 8 and Lamba expressions

Apparently, you can. Actually, it’s fairly easy to improve JUnit 4. The most obvious step is to migrate to Java 8. JUnit 5 fully embraces the new features of Java 8. In particular, now you can use Lambda expressions in assertions. As a consequence, JUnit 5 requires Java 8. It doesn’t support the older versions of the Java language. Given the mature status of JUnit 4, this isn’t even a bold step. I suppose most conservative developers who insist on using an older version than Java 8 can cope with JUnit 4.
Continue reading

Selenium Dreams

Last week I’ve blogged about Cucumber and Selenium. In the meantime, my enthusiasm has cooled down considerably. I ran into a host of problems. Browsers simply aren’t intended to be controlled remotely. Quite the contrary. A remote control for your browser is a hacker’s dream. As a consequence, browsers tend to resist the remote control. However, Cucumber and Selenium are still the best tools I know, so I continued to work with them, and by the look of it, they will continue to work with them next week.
Continue reading

How to Use Mockito to Test JSF Components

There are two strategies to write JUnit test for JSF applications. The first strategy uses a tool like Arquillian to start both an application server and a browser that runs a JSF application. Yeray Santana Borges used this strategy to contribute a couple of JUnit tests to BootsFaces.

This approach has many advantages. It runs on a real application server, and it runs on a browser that can execute Javascript. In other words, it’s a very close approximation of the real world. You can test a lot of things, including behavior and AJAX requests.

The big disadvantage is performance. It takes a while to start an application server. That’s bad if you want to run hundreds of JUnit tests on every build. Usually projects prefer to define a dedicated Maven profile to run this kind of tests. By default, the tests are skipped by the build. They are run only during a nightly build.
Continue reading