Changes between Initial Version and Version 1 of PLATFORM_STANDARDS_AUTO_TESTS


Ignore:
Timestamp:
12/20/08 14:07:27 (16 years ago)
Author:
todor
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • TabularUnified PLATFORM_STANDARDS_AUTO_TESTS

    v1 v1  
     1[[BackLinksMenu]] 
     2= Platform Standards Auto Tests = 
     3 
     4There are some important things about automatic testing of Sophie 2.0. 
     5 
     6All 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. 
     7 
     8== General rules == 
     9 
     10    * The test2/net/asteasolutions/veda/testing/ contains the base infrastructure for testing 
     11    * test2/net/asteasolutions/veda/ contains some suites - !AllTests, !AllUnitTests, !AllSystemTests and !AllIntegrationTests. You can imagine what they are doing by their names. 
     12    * 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. 
     13    * Tests should not initialize instance fields outside of the setUp methods. This is dirty. 
     14    * Tests should really test only what they are intended to test. 
     15    * If you override setUp(), the first line of your setUp should be super.setUp()! 
     16    * If you overrid tearDown(), the last line of your tearDown should be super.tearDown()! 
     17    * Put all resources needed for testing (sample book, images, etc) into !TestBase.TEST_RES_PATH. Do not hardcode this path! 
     18    * All temporary files should be created in !TestBase.TEST_TMP_PATH. You should make sure that you erase them upon successful run. 
     19    * Most test classes should contain several (or many) test methods. It is stupid to have only one test method for unit test. 
     20    * All test methods should be short, and check ONLY what they are intended to check. 
     21    * 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 
     22 
     23== Unit Tests == 
     24 
     25The 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. 
     26Then 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: 
     27 
     28    * testCurrentBookView 
     29    * testCurrentBookView_remembers 
     30    * testCurrentBookView_validation  
     31 
     32If 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. 
     33 
     34'''Units to be tested''' 
     35    
     36   1. !TextFrame 
     37   1. !ImageFrame    
     38   1. !FrameView 
     39   1. !TextFrameView 
     40   1. !ImageFrameView 
     41   1. !FileMenu 
     42   1. !EditMenu 
     43   1. !InsertMenu 
     44   1. !WindowMenu 
     45   1. !ToolsPalette 
     46   1. !PagesPalette 
     47   1. !BookPalete 
     48   1. !FramesPalette 
     49   1. !BookTemplates 
     50   1. !PageTemplates 
     51   1. !ResourcesPalette 
     52   1. !ResourceInfoPalette 
     53   1. !Search 
     54   1. !ResourceManager 
     55   1. !FrameHaloMenu 
     56   1. !TextHaloMenu 
     57   1. !PageHaloMenu 
     58   1. !ResizePageHaloButton 
     59   1. Undo/Redo + Manager 
     60   1. !BookViewButtonsPanel - done (moved in !BookViewUnitTest) 
     61   1. !DragAndDrop 
     62   1. !DialogVizualizer 
     63 
     64== Integration Tests == 
     65The Integration test cases specifically focus on the flow of data/information/control from one component to the other. 
     66 
     67So 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. 
     68See http://en.wikipedia.org/wiki/Integration_testing 
     69 
     70'''Units to be tested''' 
     71   1. !AppIntegrTest - done 
     72   2. !BookResourceIntegrTest - done 
     73   3. !BookResourceManagerIntegrTest - done 
     74   4. !BookIntegrTest - done 
     75   5. !FrameIntegrTest - done 
     76   6. !FrameStyleIntegrTest - done 
     77   7. !PageIntegrTest - done 
     78   8. Book - done 
     79   9. MORE....  
     80 
     81== System Tests == 
     82See http://en.wikipedia.org/wiki/System_testing 
     83 
     84'''Units to be tested''' 
     85   1. !FileMenu - in progress 
     86   2. !MainMenu 
     87   5. Chaining 
     88   6. !DragAndDrop 
     89   7. Search