wiki:PLATFORM_STANDARDS_AUTO_TESTS

Version 3 (modified by pap, 16 years ago) (diff)

--

Error: Macro BackLinksMenu(None) failed
compressed data is corrupt

Platform Standards Auto Tests

There are some important things about automatic testing of Sophie 2.0.

All tests are currently located in the test2 directory. We shall write the new tests there. To run all tests Run AllTest class As JUnit Test.

General rules

  • The test2/net/asteasolutions/veda/testing/ contains the base infrastructure for testing
  • test2/net/asteasolutions/veda/ contains some suites - AllTests, AllUnitTests, AllSystemTests and AllIntegrationTests. You can imagine what they are doing by their names.
  • Tests should either extend one of (UnitTestBase, IntegrationTestBase, SystemTestBase) or be marked with (@UnitTest, @IntegrationTest, @SystemTest) when they do not need to inherit the infrastructure.
  • Tests should not initialize instance fields outside of the setUp methods. This is dirty.
  • Tests should really test only what they are intended to test.
  • If you override setUp(), the first line of your setUp should be super.setUp()!
  • If you overrid tearDown(), the last line of your tearDown should be super.tearDown()!
  • Put all resources needed for testing (sample book, images, etc) into TestBase.TEST_RES_PATH. Do not hardcode this path!
  • All temporary files should be created in TestBase.TEST_TMP_PATH. You should make sure that you erase them upon successful run.
  • Most test classes should contain several (or many) test methods. It is stupid to have only one test method for unit test.
  • All test methods should be short, and check ONLY what they are intended to check.
  • there are helper classes for the test cases in test2 directory - halos/HalosConstants, menus/demo, menus/mock, logic/LogicHelper, model/book/DefaultBookResource, model/persist/MiscTest, prolib/DummyListener, view/MockBookView, src/research/dialogs/TestingDialogManager

Unit Tests

The easiest way to make good unit test, is to use Eclipse generate its skeleton (that is, one test for each method of the tested class). See ​http://www.basilv.com/psd/blog/2006/how-to-write-good-unit-tests and ​http://en.wikipedia.org/wiki/Unit_testing for directions. Then change your class to extends UnitTestBase and start filling the tests. If a method is not trivial (you need to check several things) add extra test methods like:

  • testCurrentBookView
  • testCurrentBookView_remembers
  • testCurrentBookView_validation

If it is not obvious what a method is testing, add a short comment (to one sentence). If you can not write in one sentence what the test checks, then split the test.

Units to be tested

  1. TextFrame
  2. ImageFrame
  3. FrameView
  4. TextFrameView
  5. ImageFrameView
  6. FileMenu
  7. EditMenu
  8. InsertMenu
  9. WindowMenu
  10. ToolsPalette
  11. PagesPalette
  12. BookPalete
  13. FramesPalette
  14. BookTemplates
  15. PageTemplates
  16. ResourcesPalette
  17. ResourceInfoPalette
  18. !Search
  19. ResourceManager
  20. FrameHaloMenu
  21. TextHaloMenu
  22. PageHaloMenu
  23. ResizePageHaloButton
  24. Undo/Redo + Manager
  25. BookViewButtonsPanel - done (moved in BookViewUnitTest)
  26. DragAndDrop
  27. DialogVizualizer

Integration Tests

The Integration test cases specifically focus on the flow of data/information/control from one component to the other.

So the Integration Test cases should typically focus on scenarios where one component is being called from another. Also the overall application functionality should be tested to make sure the app works when the different components are brought together. See ​http://en.wikipedia.org/wiki/Integration_testing

Units to be tested

  1. AppIntegrTest - done
  2. BookResourceIntegrTest - done
  3. BookResourceManagerIntegrTest - done
  4. BookIntegrTest - done
  5. FrameIntegrTest - done
  6. FrameStyleIntegrTest - done
  7. PageIntegrTest - done
  8. Book - done
  9. MORE....

System Tests

See ​http://en.wikipedia.org/wiki/System_testing

Units to be tested

  1. FileMenu - in progress
  2. MainMenu
  3. Chaining
  4. DragAndDrop
  5. Search

Comments

  • The information in the document is out of date. Test classes are in org.sophie2.core.testing. Test resources should be placed in the /src/test/resources directory in the module that the test is in. There are a lot more unit and integration tests and I don't think every single one of them should be listed. The whole structure of the document should be revised (as part of PLATFORM_STANDARDS_AUTO_TESTS_R1) --boyan@2009-01-12
  • You may note that library test should demo how the library is to be used with some Dummy classes. --pap@2009-01-15
  • The requirement that a test method tests a cconcrete thing should somehow be noted above all other. --pap@2009-01-15
  • It should be noted thet unit tests actually define the required functionality of the tested unit. --pap@2009-01-15