dagblog.
← Archive

A panel discussion on testing applications


What happens when you put a Java developer, a .NET developer, a Python developer and a Ruby developer together and ask them to talk about application testing? I didn’t know what to expect, but I was happy to accept Jarda Jirava’s invitation to Testing Applications — A Panel Discussion. I was joined by Karel Minařík (Ruby), Jan Král (Python), Borek Bernard (Flex, .NET) and Michael Juřek (.NET), with eighty people in the audience.

First, the event went really well and the other speakers were excellently prepared. There’ll even be an audio recording online. Here are the most interesting things I took from the discussion.

With dynamic languages like Ruby or Python, tests are the beginning and end of writing code. Testing came up like a mantra for practically every part of software development. A test both shaped the design and measured the quality of the code. Test first was mentioned often as a way to decide where to start. As Pavel Jetenský rightly pointed out from the audience, you can still get away with writing applications in a statically typed language, but it’s a problem when you do it in a dynamic one.

The topic that held us up could easily fill an article of its own. It was how to prepare test data. One testing rule says preparing the data for a test shouldn’t depend on any application logic. I liked that we seemed to agree that for applications built on a database this is only a theory, and redundant data preparation tends to run out of steam pretty quickly. The schema and application constraints keep evolving, for example, and it’s hard to keep them in sync.

A few more things caught my attention.

  • Carbon footprint — The sooner you start testing at a lower level of abstraction, the fewer computers you need. Environmental fundamentalism perfected? ;-)
  • Pex — A Visual Studio extension that can go through and analyze your code and use what it learns to generate corresponding tests.
  • Borek illustrated how hard it is to write tests for different kinds of code. Tests for ordinary libraries were generally easiest to write compared with, say, desktop applications. That’s a good argument to have ready for anyone recommending their own framework to me.

Medium version

Related articles

Related CZ Podcast episodes