omar wrote:
what I really want is a LLBL generated project complete with its unit test project (what ever the unit testing framewrok is). This way I could learn how you are building your tests so that I can do the same in my own projects.
Ok, I use Testdriven.net which is based on mbunit. This is important as it uses different .config files and you need to place the connection string in a different file.
I use several databases for the unittests. I have one on sqlserver which tests generic insert/update code, i.e.: the generic code used by all databases. This is a custom database I made, which is created especially for the unittests. To make unittesting easier, I added to each table a field of type GUID in which I place the testrun ID (a guid I create at startup of the tests) and at teardown I simply call a stored procedure which removes all rows with that guid.
For fetch tests I use northwind and for each database flavor I also use a database for fetching and platform specific sql (like update/delete directly etc). These are existing databases.
I have 1 class for each testgroup, so tests are easier to find in the test set. Testing is hard though, and I found it easier to first cook up scenarios and hten write the tests for these scenarios to see if the code works, but number one element of succesful testing is: writing the tests prior or right after you've added a feature. Do not wait till the end of the project, because you'll then have to write a lot of tests which is boring and you'll forget a lot of them.
MbUnit requires a reference to their engine assembly and you have to add the connection string to a .config file which has the same name as your unittests assembly. So if your unittests are in unittests.dll, you have to create a config file called unittests.dll.config which contains the app.Config contents generated in the generated code.
Then, start with a new class, add a test setup and test tear down method, mark them with the proper attributes and then you just add tests, one method at a time. Write them as atomic as possible. It can be wise to create a utility library which creates entities for you, for example 'CreateCustomer' which creates a new entity object and fills it with random data. This way you don't have to write tedious code over and over again.
Add as much asserts as possible, but don't re-test a given piece of functionality over and over again. So if you have a test which fetches a customer and tests if that customer is fetched correctly, you don't have to test every property of the customer again in another testmethod, unless the other method does something else of course which can affect the customer fetch outcome. Either way: re-use code, so call into an entity fetch routine which does tests is preferable.
) referenced in the help file.
I think this would serve as a great guideline for use on how to implement our own unittests in LLBL generated code...