With the HUGE news of Drizzle’s first GA, I thought it appropriate that I spend some time discussing the testing that has gone into this release.
I tend to agree with Stewart’s assessment of our quality – it is solid and I think that you will find yourself pleasantly surprised and not at all angry when using it, but it is always in the eye of the user ; ) With that said, I did want to highlight some areas of interest.
To begin with, as we are a fork of MySQL, the bulk of our test suite comes directly from there as well. Most of the standard mysql-test-run tests that are used to validate MySQL are also used for Drizzle. All of the basics like creating tables, inserting data, etc – all tested just the same : ) Of course, we have also added significant numbers of new tests as development has progressed.
On top of this, we utilize a variety of other testing and benchmarking tools. It seems appropriate to describe the life of a Drizzle patch really quickly:
Once a patch is approved for trunk, we merge it into our build branch. This kicks off a set of Jenkins jobs on a variety of platforms that make sure the code will build and pass the main test suite. If it fails, we usually ask the person who submitted the patch to sort things out. We also provide for param-builds so that people can test their branches directly before proposing a merge – it is an invaluable tool.
Once the patch passes build, we move it into staging. Staging consists of deeper tests and benchmarks. We take lcov numbers, we run sysbench and dbt2, we utilize a variety of randgen tests to try to crash the server and to validate functionality like drizzledump and the transaction log. In short, we really put our code through the wringer before we ever allow it into trunk.
For this release, my efforts were focused on a few particular areas:
- The transaction log (file and innodb-based variants)
- The slave plugin
- Drizzledump restore functionality
- Drizzledump migration
- General streamlining / overhauling of testing
Additional testing was provided by the community (many thanks to everyone who helped us out with feedback!) and by the individual developers. We generally create test cases for our main suite.
We have a lot more interesting things planned for the future. There are several intriguing new features on the horizon and we are also doing some cool things with our testing tools as well.
Pingback: Last Week in Drizzle « LinuxJedi's /dev/null
Awesome Job!.
You great hunter of bugs. hats off.
Jobin.
Thanks, but really the bulk of the credit goes to the developers – I just get to try to break their hard work ; )
I only hope my efforts have helped make the software better for everyone.