All parties involved in creating applications – developers, testers, users, managers, executives – would agree, I believe , that thorough unit-testing is a good thing. It has a cost, of course, but that cost should be more than offset by the benefits, for example:
- higher initial quality, i.e. fewer bugs when dev hands over to QA
- less time spent setting up environments due to better understanding of the applications needs and behaviors
- greater clarity of requirements gained by developers designing and developing test cases
- better understanding of impact of new development on existing code
These are just a few benefits. I’ll describe more in later posts.
The holy grail of unit-testing is to not only create and run the test suite frequently but to automate those runs. When using a build technology – like Jenkins – a test suite can be linked to the build and deployment method, thus automatically running the suite after a build and prior to deployment. A further step is then to run the test suite automatically after every commit, i.e. continuous testing.
This approach to unit-testing is common in application development outside the database, e.g. Java, C#, C++, but, in my experience, very rare within it. In fact, I’ve never encountered it in my entire career – over 20 years – and a quick survey of database development teams at my current employer revealed that not only is no team doing it, but the company doesn’t have a standard or recommended toolset for it!
This would be unheard of for other development teams but it seems to be status quo for database teams; quite strange, I think.
I first encountered automated unit testing about a year ago when playing around with Hadoop. I downloaded the source code for a sample Java app that included a complete test suite. As I ran the Maven build, I watched all the messages scroll by as the tests were run and thought; Wow! This is really cool. Of course, the tests started to fail about half-way through, so that gave me something else to do!
Ever since that day, I’ve wanted to add this feature to my database work and have been researching various options. I’m using Oracle predominantly at work and developing in PL/SQL, so I started looking at my options in this area first. There are several PL/SQL tools available but none really offered the same feature set that I had seen in the Java app. I will be looking at these options in detail in future posts.
Then I started looking at Python and, after a short time, the PyTest module. Now, I began to see some real possibilities.
After studying the language and the PyTest module for a few weeks, I feel like I’m ready to put some serious effort into developing a unit test suite for my teams work. I plan to document the journey in this blog. I hope it will turn out well and bring us to a better place where we all manage to get more done with higher quality and less effort in a shorter time.
Hopefully, that is possible, right?