links to this page:    
View this PageEdit this PageUploads to this PageHistory of this PageTop of the SwikiRecent ChangesSearch the SwikiHelp Guide
SqueakDBX - Tests
Last updated at 3:01 pm UTC on 9 June 2009

Unit testing

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:

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
				host: ''
				port: '5432'
				database: 'sodbxtest'
				userName: 'sodbxtest'
				userPassword: 'sodbxtest').
	self platform: DBXPostgresPlatform new

Test Coverage

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.