We use JUnit (or similar) to unit test our code. The test should be runnable from your ant build script if at all possible. If it can't be run from the build file due to some other dependency then there should at least be some obvious documentation on how to run it!
Running the core projects unit tests
The unit tests for the core projects need to be run in particular order. All of the projects need the test data loaded from lams-common, and some need data from other projects.
In many cases, the tests for a project can only be run once. Then you need reload the test data (using lams-common). This is due to how the tests have been written - the authors have embedded the "expected" id number of newly created records. We will try to rewrite these tests gradually to avoid this issue.
The tests in lams-common and lams-contentrepository appear to just need the test data loaded and can probably be run in any order.
Each time you run insert-test-data, you really should clear the content repository. This can be done by deleting all the folders and files in the /tmp/repository disk area.
- In lams-common run test-report. This task includes loading the test data (insert-test-data).
- In lams-contentrepository, run test-report.
The tests in lams-central need a clean set of test data before running so you must run insert-test-data and clear the content repository before rerunning the tests.
- In lams-common run insert-test-data.
- In lams-central, run test-report.
Lams_monitoring, lams_learning and lams_tool_survey are interrelated. Reload the common test data and generate the survey tables before starting on these projects. These must be tested in this order to work reliably. If you encounter a problem partway, then you will need to run through all of these again.
- In lams-common, run insert-test-data.
- Delete the folders/directories under /tmp/repository. Under Windows it will usually be D:\tmp\repository.
- In lams-tool-survey, run build-db.
- In lams-monitoring, run test-report.
- In lams-learning, run test-report.
Tips for writing junit test
- If possible, base your test cases on AbstractLamsTestCase. It requires you to define a couple of methods, but this class will take care of the Spring context. It also has useful methods like getMaxId() for getting the max value from a column from any arbitrary table.
- Use the /org/lamsfoundation/lams/localApplicationContext.xml file, rather than the normal applicationContext.xml file. This will give you a local datasource rather than a JNDI datasource. You will need to declare your own Hibernate transaction manager rather than
being able to use the shared manager.
- Try to write your tests so that they can be run multiple times without having to reload the test data.
- You will often need to refer to a record in the database loaded by the insert-test-data. Define the id using a variable in your test class, rather than embedding the id in the function call. Make the name relate to the data, rather than test case if possible. For example, MELCOE_WORKSPACE_ID is more meaningful than NEW_ID. This makes it much easier for people to understand what your test case is doing, and makes it much easier to update the test code if the common test data changes.
- In your test-suites, do not make one test dependent on another if possible, as there is no guarantee that another junit engine will run them in the same order. For example, creating a row in testCreateFunction and then updating the newly created row in testUpdateFunction is dangerous. In some cases it is better to test more than one method in the class under test (which is usually a no-no for junit) if it means that individual tests are less dependent on each other.
- Don't using files accessed from your hard disk unless they are either generated by the test code or refer to a file in the test packages. For example, don't hardcode access to a file "c:\temp\text.txt" in a test case. Please have a look at the zip file utility tests in lams-common, or the workspace service tests in lams-workspace for ideas on how to load files from the package or create the file on the fly.
If your tests has "gotcha's" which will make life harder for people to maintain them or run them - and sometimes this is hard to avoid, then please document them.
The following tests are known to be failing (29 Aug 2005)
- TestLearningDesignDAO testCalculateFirstActivity
- TestToolDAO testGetToolByID
- TestDateUtil testConvertFromStringString
- TestWebUtil Problems accessing web.xml file (which has been moved elsewhere).
- TestToolContentHandlerImpl Exception not thrown as expected
- TestSimpleRepository Descriptions wrong
- TestSimpleVersionedNode NullPointerException and invalid node type
- TestAuthoringService testStoreLearningDesignDetails
- TestWorkspaceManagement testCopyFolder, testDeleteFolder, testDeleteWorkspaceFolderContent
The TestAuthoringService testStoreLearningDesignDetails is failing as there appears to be a shortcoming in the authoring code - it always creates new learning designs rather than updating them. The testcase was improved to pick up this shortcoming. This isn't a trivial bug to fix, so the test case has been left as is so we know we have to fix this problem!
- The TestToolContentHandlerImpl testUploadFile is failing due to a deletion not occuring. The problem doesn't seem to occur under JBOSS, only when running junit, so its a problem we'll have to come back to later.
- TestLearnerService testKnockSynchGateClosed. No idea on this one.
File Submission Tool
The following tests are known to be failing (9 Sept 2005)
- TestModel. The test that fails changes. Could it be an issue with date/time fields?
- TestSubmitFilesService.testRemoveToolContentSessionDataExists and testRemoveToolContentNoSessionData
The last three have the same error - the code to look up the SubmissionDetails by content id is wrong - it is referring to a column that doesn't exist in the table.
When this is fixed, I suspect that testRemoveToolContentSessionDataExists in the Service test will still fail - the code doesn't appear to take the session data flag into account properly.
All of the Action tests are also failing - wrong urls, wrong parameters, etc. These need rewriting.