This talk will contain my opinionated views on several topics, including, but not limited to:
- Which areas of testing are well catered for, and which are not?
- What sources of bugs are frequent, and very hard to test?
- Should we perhaps start talking about unit tests less, and start talking about other forms of testing more?
In my day job I spend a lot of time looking at projects that are part of Ubuntu, and trying to find out why they’re being released with bugs. This in turn leads to a lot of dissection of test suites, and a lot of discussion with my colleagues around tests, names of tests, why some tests are better than others, where the common gaps in test coverage are, how applications should be tested, where, when, and why certain test suites should be run, and other subjects too boring to mention.
Having done this for several years, I've started to form a few troubling thoughts about the state of automated testing in software development, and in python specifically. When taken together, these can start to form a rough and ready 'testing philosophy' - a way of looking at code and, by analysing it's structure and visibility, start to find gaps in it's test coverage.
This talk contains no silver bullets - no magical solutions, but does (hopefully) contain some interesting questions.