Few guidelines on unit testing derived from my experience

When I first started using unit testing in my practice, I had no idea what I was doing. I was also frustrated. It made little sense to me to have everything unit tested because writing tests and preparing test data took me too much time.

Ever felt the same way? Don’t understand where and when to write test and where you should leave the code alone? Don’t worry, this is normal. This happens to everyone who tries to improve the way he/she does software. I can’t give you a concrete prescription, no one can, but in this post, I will share what worked for me in terms of unit/automated testing. This will, probably, work for you.

Don’t write unit tests for simple cases. One objective way to measure the return on investment (ROI) from unit tests is to measure how much time they save for development team by catching regressions. In simple cases, when the code is not going to be changed or code is pretty straightforward it is unlikely that you will get regressions, therefore it is likely that you will have no ROI at all from your unit tests. Furthermore, you will need to maintain them. The law of diminishing returns works here. You can get 80% of the benefit from covering only 20% of your code with tests. This 20% of code contain your core business logic, which delivers the most value to your customers. Everything else is some kind of glue code, configurations, mappings, frameworks, libraries interoperations and so on. The more effort you put to cover this code, the less ROI you will have.

Do large acceptance tests for refactoring. If you plan to do some large refactoring or restructuring, classical unit tests will not help. In fact, they will go into your way. Classical unit tests are small and test some small parts of the system. When you start changing things, unit tests start glowing red and you will need to delete them. The large acceptance test captures the whole business case of interaction between your system and the user. Such a business case is something that brings real value to the business and should not be changed during refactoring. Relying on acceptance tests will increase your chances to refactor without damage to the business. In developeronfire podcast, Nick Gauthier (episode 149) reported that he had his largest success in the career by moving the web application he worked on from classical client-server architecture, where HTML was rendered on the server, to the single page application (SPA). Acceptance tests made transition really smooth for his team. My refactoring team at SimCorp also had a big success of not jeopardizing our product’s quality by major refactoring we did. That refactoring touched almost every user screen in the system. My team lead insisted on having large acceptance tests suite, which eventually ensured our success.

Unit test complex algorithmic stuff by classical unit tests. As you probably know there is classical and London school of TDD. According to the classical school, unit test just applies input data to the system under test, harvest the results and compare them to expected results. According to the London school, unit test invokes system under test and then checks if it behaves as expected, i.e. it calls its collaborators correctly and in the correct order. While I feel frustration from unit testing simple cases, I get a lot of value from classical TDD when I develop complex algorithms. Value, in this case, comes from regressions which happen during initial development, because when you develop a complex piece of software you can potentially spend days in one unit trying to put things together. I vividly remember one programming exercise from my SimCorp days. I had to develop a program, which would take APL data structure of any complexity (for instance matrix of matrices) and generate APL code which would recreate this particular data structure. My first attempt failed because after 4 ours of work I was far from being done. And most of this time was spent on retesting program operation with different types of inputs after every change to the algorithm. Next day, I have tried classical TDD. And the process was not only fun but also fruitful. In about 4 hours I was done with approximately 30 tests. I remember my impression was that I would not have finished such a program in this amount of time and confidence without unit tests.

Apply London school TDD to the integration code. What if your core business logic is not algorithmic one? What if you bring the value on the table by integrating different systems together? For a very long time, it was an open question for me. In such a cases I still want to be sure my core code is tested well. However, classical tests are awkward because integrators often don’t even have inputs or outputs. I believe London school tests are perfect for them. Once, at StrategicVision, I had to develop a system that would download videos from video hosting services, extract audio from those videos, transcribe audios and finally save transcriptions and video links to the database. No business logic in a classical sense, right? My code just invoked video hosting web service, then invoked downloader, then invoked transcription web service and finally invoked repository to store results. I wrote a bunch of tests which were testing, for instance, such facts: if the system under test invoked downloader for a particular video, it should later invoke clean up for this video; if the system under test invoked database repository to store results, before that it should invoke transcription web service.

These guidelines are highly subjective of course, but at least they work for me, at least at this point in my career. Hopefully, you will also find them helpful.


Віддалена розробка програмного забезпечення (Вебінар)

Вчора продовжив свою вебінарову подорож. Цього разу вирішив зробити експеримент і провести вебінар на не технічну тему та зі співавтором, Анею Зубенко, у формі інтерв’ю. Вийшло класно, дещо розтягнуто, але це ж було інтерактивне інтерв’ю і ми намагалися невимушено обговорити багато тем та відповісти на більшість запитань, що глядачі задавали. Словом багато фану, судячи з коментарів у чаті під час вебінару, народ теж отримав позитивний заряд! Там більшість інформації – аудіо, тож цілком можна його вилучити та послухати в навушниках по дорозі кудись. Приємного прослуховування!


My 7 favorite podcasts

I am a big podcasts fan. I listen to them all the time when I am waiting for something or commuting. They help me immerse into the western technology world from which Ukrainian tech community is quite disconnected. It is extremely unusual for me to meet at the conference some kind of world recognized guru or thought leader. Podcasts can not fully compensate for that because I can not ask questions while listening (and sometimes I desperately want to do so) but still I can hear other ask questions and those questions are sometimes even better then I could have asked. Podcasts also help me as non-native English speaker to improve and maintain my English communication skills. It is sometimes very difficult for the non-native speaker to understand the native speaker and accents of other non-native speakers. Podcasts actually provide great training on listening and understanding all these different accents, because podcast guests are people from all over the globe. It is hard for me to explain the reason, but podcasts help me to write and talk about technical topics in English. Probably this is the quantity to quality transformation. I listen a lot and spoken patterns are carved into my mind so that I can use them later in my own speech. Many people are surprised to learn that it is much more easy for me to explain something software related in English than in Ukrainian. So, here is my list:

.NET Rocks. I revolve mostly in Microsoft space. And there .NET Rocks is the number one podcast. It is not only about .NET, their episodes cover many different topics, related to software development in the Microsoft universe. Of course, most episodes are about .NET but often you will hear about the broad range of topics, starting from machine learning and ending with front-end stuff. Not only .NET rocks will keep you up to date with latest advances in .NET but it will also entertain you, I often find myself laughing or smiling while listening.

Javascript Jabber & Adventures in Angular. These two podcasts cover my front-end needs. I mention both because they are made by the same guy although the set of panelists differ. You will learn about advances in JavaScript and Angular worlds, learn about new libraries, front-end development problems, and possible solutions. In every episode, they discuss so-called picks, different things which podcast authors and guests are currently excited with. These picks will really teach you a lot.

SE-radio. This one was my first podcast. It mostly covers fundamental aspects of software development like refactoring, architecture, programming languages design, requirements engineering, software modeling, distributed and real-time systems. Back to the previous decade it was created and lead by Markus Voelter, who is my favorite podcaster. First, he is german but his English communication skills are extraordinary. Because he is not a native-speaker, his speech is simple and clear, the way he asks questions and digs into technical topics can be used as an etalon. It is also clear that the guy is passionate about podcasting and technology and for me it is a big deal, I love passionate people. This days se-radio is produced by IEEE Software magazine. Markus does not participate in its production anymore, but it is still pretty interesting to listen world-class experts talking on fundamental aspects of software.

Omegataupodcast. I have already mentioned Markus Voelter. After he finished with se-radio, he started Omegataupodcast. The podcast is about science and engineering. Although there are episodes on biology and social science, most episodes are about space engineering and science, aviation, physics, and computing. I have a background in radio engineering and aviation, therefore, omegataupodcast meets my interest in this kind of topics. It is a combination of Markus’ brilliance in dissecting complex technical topics and great science content which can literally go on for hours (episodes are pretty long).

Hanselminutes. It is hard to tell why am I listening regularly to this podcast. It is short, it has no specialization it looks and feels like the ordinary podcast, there are thousands of such. Probably because I have huge respect for Scott Hanselman and for all he does. He is the brilliant guy and he can combine interesting topic with fun conversation. Probably it is because ridiculously wide variety of topics covered on the podcast. One week he can talk on excel spreadsheet, another week – about toy robots, yet another week – some soft skills topic like management, motivation, and creative processes.

Developeronfire. I have recently discovered this podcast, I have listened to almost all old episodes and never miss new episodes. It is not technical and you can listen to it while working out when you can not concentrate very much. The podcast is indeed about going personal with your favorite geeks. Dave, the host, invites to talk about personal stuff active people in the software world. Mostly developers but not only, there were consultants, managers, marketers and other professions on the show, all somehow related to software development. Dave asks more or less the same set of questions like what is it the guest likes about technology, guest’s definition of value, his biggest success, and failure, her hobbies, and value delivering tips. Sometimes the guest is moderate and you will not hear something special and sometimes whole episode is full of pearls of wisdom. Take for instance episodes with Scott Hanselmann, DHH, J.B. Rainsberger or Linda Rising. Highly recommended, a lot of fun, deep conversations and you will be surprised how many things will resonate with you and your experiences in the industry. Cool stuff there.

EconTalk. This podcast is not specifically about technology or software, although some episodes are, but it is about everything else. Most episodes are discussions between the host and some brilliant personality who has written some great article or book. EcanTalk is meant to be about the economy but it is about the economy in a very broad sense. The topic can be very economy related like agriculture, chicken production, banking and monetary policy. They can also discuss somehow related to economy topics like machine learning, technology and artificial intelligence influence on the economy of the future, peoples’ ego, learning and education problems, sports, healthcare, and transhumanism. To summarize: this is a podcast where extremely smart people discuss very interesting and essential to everyday life problems.