I recently finished Effective Software Testing – A Developer’s Guide by Maurício Aniche, and I really liked it. I have been coding for a long time and I think I have been writing pretty good tests for the features I have implemented. Even so, I found this book quite valuable. Particularly the chapters on how to systematically come up with test cases based on the specification, inputs, outputs and the structure of the implementation.
Posted in Programming, Testing
Tagged book, book review, developer testing, review, testing, unit testing
Choosing test values when writing unit tests is mostly guided by the need to cover all cases of the program logic. However, some values are better than others. Here are a few tips on how to pick values that make mistakes easy to spot and the tests easy to read. Plus a bonus tip on a quick way to double check your tests.
You have developed a new feature. The code has been reviewed, and all the tests pass. You have just deployed this new feature to production. So on to the next task, right? Wrong. Most of the time, you should check that the feature behaves as expected in production. For a simple feature it may be enough to just try it out. But many features are not easily testable. They may be just one part of a complex flow of actions. Or they deal with external data fed into the system.
In such cases, checking if the feature is working means looking at the logs. Yet another reason for checking the logs is that the feature may be working fine most of the time, but given unanticipated data, it fails. Usually when I deploy something new to production, I follow up by looking at the logs. Often I find surprising behavior or unexpected data.
A few weeks ago I spoke at the EuroSTAR software testing conference in Prague. The conference had one and a half days of tutorials, followed by two and a half days of talks. Around a thousand people attended. I was impressed by the sense of community and by the number of activities offered. For climate reasons, I chose to travel there and back by train instead of flying.
Continue reading
I like to use Test-Driven Development (TDD) when coding. However, in some circumstances, TDD is more of a hinderance than a help. This happens when how to solve the problem is not clear. Then it is better to first write a solution and evaluate if it solves the problem. Writing tests only makes sense after the solution is viable.
Continue reading
At the end of May I attended Nordic Testing Days in Tallinn, Estonia. It was the first time I spoke at a conference outside of Sweden, and I had a great time. There was one day with tutorials, and two days with workshops and regular half hour talks. Here are my impressions:
Continue reading
For the past few years, I have heard many people advocating using only automatic tests. For example, if all the automatic tests pass, then the code should automatically be deployed to production. I have always performed a bit of manual testing before feeling confident about my code. So for the past year I have paid extra attention to bugs I have found manually testing my own code. My conclusion: manual testing is still needed.
Continue reading
Posted in Testing
Tagged exploratory testing, integration testing, testing, unit testing
I recently found out about the book Developer Testing – Building Quality Into Software by Alexander Tarlinder, and I immediately wanted to read it. Even though I am a developer at heart, I have always been interested in software testing (I even worked as a tester for two years).
I think the subject of the book, developer testing, is timely. There seems to be a broad trend where more and more responsibility for testing is given to developers. It follows from the move towards micro services, dev ops and the “you built it, you run it” principle. Another driving force is the prevalence of developer testing frameworks that started with JUnit and now includes many more. These frameworks encourage and help developers write automatic tests.
Despite this trend of increasing developer testing, my feeling is that many developers still don’t test their programs well enough. For example, they may test the “happy path”, but not the different error handling cases. That is why I was excited about this new book explicitly addressing developer testing. Continue reading
Posted in Programming, Testing
Tagged book, book review, developer testing, review, testing, unit testing
In Learning From Your Bugs, I wrote about how I have been keeping track of the most interesting bugs I have come across. I recently reviewed all 194 entries (going back 13 years), to see what lessons I have learned from them. Here are the most important lessons, split into the categories of coding, testing and debugging:
Bugs are great learning opportunities. So how do we make sure we learn as much as possible from the bugs we fix? A method I have used for more than 13 years now is to write down a short description of the bug, the fix, and the lessons I learned.
Way back in 2002, I came across a blog post by Bill Wake that described this method. I have used it ever since, and I believe it has helped me become a better software developer.
Every time I fix a particularly tricky or interesting bug, I take a few minutes to write down some facts about it. Here is an example of a typical entry: Continue reading
Posted in Debugging, Learning, Programming, Testing
Henrik Warne's blog 