Author:halw

Date:2012-05-11T21:25:16.000000Z


git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@1096 abb3cda0-5349-4a8f-a601-0c33ac3a8c38

documentation/current/eiffelstudio/_images/AutoTest_General_pane.png.data

@@ -0,0 +1,3 @@
+title=AutoTest General pane
+author=halw
+path=content/autotest-general-pane

documentation/current/eiffelstudio/_images/AutoTest_General_pane_empty.png.data

@@ -0,0 +1,3 @@
+title=AutoTest General pane empty
+author=halw
+path=content/autotest-general-pane-empty

documentation/current/eiffelstudio/_images/AutoTest_add_cluster_dialog.png.data

@@ -0,0 +1,3 @@
+title=AutoTest Add Cluster dialog
+author=halw
+path=content/autotest-add-cluster-dialog

documentation/current/eiffelstudio/eiffelstudio-guided-tour/using-autotest/create-manual-test.wiki

@@ -169,35 +169,93 @@ Now you should see the coverage tag in the list of '''Tags used in new test'''.
 That takes care of adding our coverage tag, so let's click '''Next''' to go to the next wizard pane, the '''General''' pane.
 
 
-[[Image: AutoTest General pane]]
+==The General Pane==
 
 
+[[Image: AutoTest General pane empty|The General Pane]]
+
 
 We will use this wizard pane to name our test class and let AutoTest know where we want the test class to reside. You can give a test class any name you wish, as long as it doesn't conflict with another class name in your system. If you try to type in a class name that already exists, the wizard will let you know right away by changing the text color to red. There is a convention that has arisen around test class names. If possible make the test class name the name of the target class, prefixed with <code>TEST_</code>. So in our case, we want to build a test against a feature of the <code>BANK_ACCOUNT</code> class, so we will name our test class <code>TEST_BANK_ACCOUNT</code>.
 
-Now, for the question of where the tests should be kept. Again, you can keep them anywhere you wish, but there are some advantages to keeping the test classes in a '''test cluster''' separate from your target classes. For example, it will be easier for you to deliver your application or library classes if the testing classes are mixed it. A '''test cluster''' is just a cluster of classes that EiffelStudio and AutoTest expect to contain test classes. So we want to create a new testing cluster as a subcluster of the cluster in which the classes <code>APPLICATION</code> and <code>BANK_ACCOUNT</code> reside. 
+Now, for the question of where the tests should be kept. 
 
-Notice the '''New cluster''' button ( [[Image:16x16--new-cluster-icon]] ) on the wizard pane above. We click that button to add a new test cluster. The '''Add Cluster''' dialog box appears:
+By default, tests will be stored in a subdirectory of the EIGENs directory that is generated by the Eiffel compiler. Because it's the default, it's the quickest, easiest way to house tests. But it may not be the best for you in the long run. For example, if you manually delete the EIFGENs directory, which is occasionally necessary, you will lose your tests.
+
+You could include them in the same cluster as some of your application classes. But there are some advantages to keeping the test classes in a '''test cluster''' separate from your target classes. For example, it will be easier for you to deliver your application or library classes if the testing classes aren't  mixed with your domain classes. A '''test cluster''' is just a cluster of classes that EiffelStudio and AutoTest expect to contain test classes. So, in our case, let's create a new testing cluster as a subcluster of the cluster in which the classes <code>APPLICATION</code> and <code>BANK_ACCOUNT</code> reside. 
+
+First, uncheck the box labeled '''Use EIFGENs cluster'''. 
+
+Notice the '''New cluster''' link on the General pane. We click that link to add a new test cluster. The '''Add Cluster''' dialog box appears:
 
 
-[[Image:AutoTest new test wizard Add Cluster 01]]
+[[Image:AutoTest Add Cluster dialog]]
 
 
-As with test class names, there is an emerging convention for the name of a test cluster: <code>tests</code> . So we will name our test cluster <code>tests</code> and make it a subcluster to our root cluster <code>accounts</code>. Notice that there is a '''test cluster''' check box on the dialog. It is checked and disabled, so at this point in the wizard you would always create a test cluster. Once the test cluster is created, we're back to the second wizard pane which now looks like this: 
+We can name our test cluster <code>tests</code>, the default, and make it a subcluster to our root cluster <code>accounts</code>. Notice that there is a '''test cluster''' check box on the dialog. It is checked and disabled, so at this point in the wizard you would always create a test cluster. Let's also check the box labeled '''recursive'''. Once the test cluster is created, we're back to the General pane which now looks like this: 
 
 
-[[Image:AutoTest new test wizard 02M 02]]
+[[Image:AutoTest General pane]]
+
+
+At this point we have provided all the information necessary for AutoTest to create the shell for a manual test on the <code>deposit</code> feature of the <code>BANK_ACCOUNT</code> class. 
+
+So, now we click '''Launch''', and AutoTest creates our test set and test. 
 
 
 
+==Writing a test==
 
-After clicking '''Next''', we see the third pane of the wizard. In this pane, we will describe our manual test routine. It looks like this:
+Let's look at the class <code>TEST_BANK_ACCOUNT</code>:
 
+<code>
+note
+    description: "[
+        Eiffel tests that can be executed by testing tool.
+    ]"
+    author: "EiffelStudio test wizard"
+    date: "$Date$"
+    revision: "$Revision$"
+    testing: "type/manual"
 
-[[Image:AutoTest new test wizard 03M 01]]
+class
+    TEST_BANK_ACCOUNT
 
+inherit
+    EQA_TEST_SET
 
-Here we will name our test. Let's say that we plan to write this test against the feature <code>{BANK_ACCOUNT}.deposit</code>. Like the naming convention for test classes, we'll give this test the name <code>test_deposit_01</code>. The prefix <code>test_</code> before the feature name it will test, and the suffix <code>_01</code> so that we have a framework for adding more tests against <code>deposit</code>. Again, you can choose any naming scheme that makes sense to you. You may want to try to describe the test in its name. For example, <code>test_deposit_very_large_amount</code>.
+feature -- Test routines
+
+    test_deposit_01
+            -- New test routine
+        note
+            testing:  "covers/{BANK_ACCOUNT}.deposit"
+        do
+            assert ("not_implemented", False)
+        end
+
+end
+</code>
+
+We can see that the feature <code>test_deposit_01</code> exists, but doesn't really test anything. So, let's change that. We'll alter <code>test_deposit_01</code> so that it creates an instance of <code>BANK_ACCOUNT</code> and then makes a deposit to that account. 
+
+So, <code>test_deposit_01</code> now looks like this:
+
+<code>
+    test_deposit_01
+            -- New test routine
+        note
+            testing:  "covers/{BANK_ACCOUNT}.deposit"
+        local
+            l_ba: BANK_ACCOUNT
+        do
+            create l_ba
+            l_ba.deposit (500)
+        end 
+</code>
+
+Now we have created and written a manual test using AutoTest.
+
+Next let's look into the notion of '''Tags''' in a little more detail, then see what it takes to execute a test.
 
 
 ==About Tags==
@@ -278,58 +336,3 @@ execution/serial/group_2
 then AutoTest will not run any <code>group_1</code> tagged test concurrently with any other <code>group_1</code> test, and likewise for tests tagged <code>group_2</code>.
 
 
-==Writing a test==
-
-Let's look at the class <code>TEST_BANK_ACCOUNT</code>:
-
-<code>
-note
-    description: "[
-        Eiffel tests that can be executed by testing tool.
-    ]"
-    author: "EiffelStudio test wizard"
-    date: "$Date$"
-    revision: "$Revision$"
-    testing: "type/manual"
-
-class
-    TEST_BANK_ACCOUNT
-
-inherit
-    EQA_TEST_SET
-
-feature -- Test routines
-
-    test_deposit_01
-            -- New test routine
-        note
-            testing:  "covers/{BANK_ACCOUNT}.deposit"
-        do
-            assert ("not_implemented", False)
-        end
-
-end
-</code>
-
-We can see that the feature <code>test_deposit_01</code> exists, but doesn't really test anything. So, let's change that. We'll alter <code>test_deposit_01</code> so that it creates an instance of <code>BANK_ACCOUNT</code> and then makes a deposit to that account. 
-
-So, <code>test_deposit_01</code> now looks like this:
-
-<code>
-    test_deposit_01
-            -- New test routine
-        note
-            testing:  "covers/{BANK_ACCOUNT}.deposit"
-        local
-            l_ba: BANK_ACCOUNT
-        do
-            create l_ba
-            l_ba.deposit (500)
-        end 
-</code>
-
-Now we have created and written a manual test using AutoTest.
-
-Next let's see what it takes to execute a test.
-
-