SqueakDBX - Tests
Last updated at 3:01 pm UTC on 9 June 2009
We have spent a lot of time and effort on unit testing. This is because we really believe and are convinced about the benefits of them. Till now we have aprox. 94 unit tests. These tests not only are for us, but also for you. Reading a unit test, you can see the public interface of an object, what it shows, how it must be used, and so on. So, we strongly recommend you read the tests in order to use SqueakDBX properly. We believe this is really useful and will help you.
How to run the tests
Before running the tests (any of them) you must do three things:
- Compile and install OpenDBX. You can see how to do that in this link: SqueakDBX - Compiling and installing OpenDBX.
- We have a lot of types of tests, for example we have DEBXConnectionTest, DBXQueryTest, DBXOptionsTest, and so on. In addition, we have a lot of backends to test. But we didn't want to create for each type of test a subclass per backend. So we introduced the concept of "facility". This is a class that provides to the different types of tests, the information for a specific backend (you will have a facility per backend). When running the tests you will be asked what backend to run and this is stored in a class side variable. The following tests will be run with this backend (till you run DBXResetTestBackend). To resest this value, you can run the test DBXResetTestBackend. You may notice DBXResetTestBackend is not actually a test, it just resest the environment. After running this particular test, if you then run the tests you will asked again to choose the backend.
- Run a script into the database for creating the database, user and password that will be used in the unit tests. This script can be optional if you want to user other user or database, but if you do this, you must change the database connection settings (see "Changing unit tests database connection settings" ahead). See the scripts here: SqueakDBX - database scripts.
Changing unit tests database connection settings
As we told you above, the specific information for testing a backend, is in the facility. So, suppose you want to change any connection settings used in all unit tests, you should change the class side method "createConnection" of the particular subclass of DBXBackendFacility. There you can change whatever you want. Example for PostgreSQL:
self connectionSettings: (DBXConnectionSettings
self platform: DBXPostgresPlatform new
Till now, we have 58% of test coverage. To test this, just run Test Coverage from Test Runner. Class side method packageNamesUnderTest was added in tests.
Test for all backend
There is a simple way to run all the tests for all backends. This is mainly used by us, but you can also use it. This is not continuous integration but let us sure that we didn't break anything in all backends. This test is DBXFullTestRunner #testAllBackendsWithAllTests. But, as not all the programmers have all the backends running, we did this test as felxible as needed. So, it actually doesn't test ALL backends and ALL tests, but the one you tell it in the class side messages backendsToTest and testsToTest. You can modify this two messages for the backends you have.
Test looking memory leaks and similar
You all know that working with C we can have errors related with memory management. These errors are very difficult to trace, debug and find because they often occur randomly. Perhaps you run a a suite of tests and works well, but after running it several times, you get a segmentation fault. So, we did a test that tries to discover those errors. What it actually does is very simple: it runs several times all the tests for a specific backend. If your image crashed and gets a segmentation fault, it means there is a bu somewhere :) If you were luck, you will see a green bar. To run this "test" you evaluate something like this: DBXFullTestRunner new test: DBXMainBackendTestPostgresql times: 20.