When first starting my employment at Garmin, most of the existing tools did not have tests. Testing was performed by simply making sure that the requested feature worked or that the reported bug was fixed. However, there were no regression checks and as you might be able to imagine, our tools were very unstable. Introducing a change had a very high probability that it would break some other existing feature or introduce a new bug. When you have hundreds of developers depending on your tools it is not acceptable to allow them to be broken the majority of the time and in our case it happened often. As such, I was assigned the task of writing tests for one of our big Python projects.
I've been writing tests for this particular project for about a year now and have written the majority of the framework from scratch. In doing so, I've learned and developed what I deem to be good practices when creating a testing framework and when writing the tests themselves. Over the course of the next several articles, I'm going to document how I set up a testing/project structure, show the difference between Unit and System tests and how I write both, and how to fully utilize the Object Oriented nature of Python in order to write DRY tests without introducing logic.
First, we will begin with Project structure.