Writing a application that must run on many different platforms, works with multiple databases and is based on emerging technologies can be very challenging. Especially when the development is distributed and has been in progress over a long period of time. As we've worked on Gallery2 we've found issues with the design and implementation that make us want to rework large parts of the system. However, we fear making large changes because even though G2 is modular and well written there are still interdependencies between different parts of the system and there's the chance that we're breaking something critical. After all, how do we have to know that our change is going to work on all of our platforms and databases without doing a lot of exhaustive and manual testing? This can be daunting and it tends to impose a conservative mindset where we fear to enact change because we know that we won't be able to find out the consequences until its too late. That is unacceptable; we must be willing to make large changes or we'll get stuck with an inferior design.
Enter Test Driven Development.
This is a strategy whereby every new bit of functionality starts its life as a test. We envision the feature and then write a test that will only succeed when the feature is complete. Initially when we run the test it fails because we haven't written the feature yet. Then we go and write the feature until it satisfies the test. If we think of a new twist or restrictrion on the feature then we write a new test and then keep working on the code until that test passes also. Pretty soon we have a very large set of tests, and all of our code is getting tested regularly. If we find something that doesn't look right, or can be combined with other code we can feel free to make as many small or large changes as we want, as long as when we check the changes in the tests still run. Find a bug? Write a test that fails until the bug is fixed. Want to add a feature? Write a test first. Code running slow? Refactor and optimize at will as long as the tests still run. Want to know if your code is going to work on a different platform? Go to that platform and run the tests. Find a bug on that platform? Write a test to expose the bug, fix the bug so that the test works, check it all in and then go and run the tests on the first platform.
G2 uses a system called phpunit to do unit testing and at the time of this writing has about 1300 tests covering all of the features in the product. If you want to see what the test suite looks like, install G2 and browse to gallery2/lib/tools/phpunit/index.php. All the tests should be green, at all times.
Test Driven Development is not our idea. It stems from a methodology called Extreme Programming. Bharat learned about Extreme Programming while doing development on SourceForge, grew enamored of it and decided that while not all principles could be applied to an open source project like Gallery, at least some of them were of tremendous value. For more information about Extreme Programming read these links:
Although the following online book chapter explains unit tests using another framework in another language (python), it does a very good job at giving a hands-on tutorial on how to write unit tests and what showing what they are good for:
Clean code is important, especially when many developers are collaborating. Read and obey the Gallery 2 Coding Standards document
Also see: Gallery Coding Guidelines
