As software developers, we spend a lot of our time writing code. Whether we're implementing new features, fixing nasty bugs, or doing boring maintenance work, there's always some code we either create from scratch or try to modify for the better. When writing code, we need confidence in what we do. We need to know whether our changes work as intended. That's why we write tests after or, preferably, before touching any code. So, inevitably, a huge part of our daily work comes down to these two things: programming and testing.
Programming and testing are, of course, only vague terms, and their meaning depends on how exactly you approach software development. For example, when practicing test-driven development (TDD), you typically follow these steps:
Even if you don't practice TDD (you totally should!), you're probably still going to:
In order to write an actual program, you have to run through these steps -- this loop -- again and again. The point is that no matter what development method you prefer, constantly jumping back and forth between programming and testing comes at a price: it doesn't just slow you down in terms of time spent (especially with long-running tests), the involved context switching also drains your mental energy, which might ultimately destroy your productivity. For this reason I believe that the following statement is so important -- and I'm not tired of repeating it whenever I get the chance:
When it comes to programming and testing, fast feedback is everything.
Here, fast feedback means that the time between changing code (or tests) and getting results from running the tests is reduced to a minimum. In other words, you end up with a fast edit-compile-test loop (the compile step is optional, of course). The great thing about this, as Joel Spolsky put it: "the faster the Edit-Compile-Test loop, the more productive you will be".
There are a couple things you can do to shorten the feedback loop. Certainly the first technique that comes to mind is isolated testing, which involves eliminating (slow) external dependencies like databases. This topic has received a lot of attention lately and I won't go into it here (by the way, TDD isn't dead). You should absolutely invest in your tests and make them faster. Besides trying to implement faster tests, however, you can also optimize the way you run them.
Time for another episode of The Jimdo Sessions. A few weeks ago, Robin Böhm visited us in our office in Hamburg. He's well known for having written the first German AngularJS book, which is already successful. At this point, we'd also like to thank him for sending us a copy. It's a great introduction to AngularJS, and if you prefer German books over English ones or you are just curious about what Robin has to share, make sure to check it out.
But enough of this, so we invited him to our office to share his thoughts about the expert levels of AngularJS. Because at Jimdo, we already use AngularJS in the latest parts (we will share
details when we have released that thingy). Of course, we also recorded his talk, so you can also enjoy it now. So here you go:
Wow, it’s the 9th Jimdo Session already. We came up with this thing really unintentionally, but everyone liked the format so we decided to keep it. For this edition Alexander Reelsen from
Elasticsearch joined us for a Friday, together with his two colleagues, Britta (Machine Learning expert) und Honza (author of The Python Client).
We met him at the Developers Conference Hamburg 2013 and invited him right away to join us for a Jimdo session, since we are always interested in meeting the people behind the products we
(A first draft of this blog post originally appeared on my personal blog: Wait for It…a Deep Dive in Espresso's Idling Resources)
One of the challenges developers have to face when writing UI tests is waiting for asynchronous computations or I/O operations to be completed. In this post I'll describe how I solved that problem using the Espresso testing framework and a few gotchas I learned. I assume you're already familiar with Espresso, so I won't describe the philosophy behind it but instead I'll just focus on how to solve that problem the Espresso way.