Author:halw

Date:2009-02-25T15:28:38.000000Z


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

documentation/current/eiffelstudio/eiffelstudio-guided-tour/using-autotest/execute-tests.wiki

@@ -51,7 +51,7 @@ Here you see under "Tests" the project cluster <code>bank_account</code>, the te
 {{note|If you've been working along in EiffelStudio, and you don't see this display, then go to the View combo box and type in "class" as shown in the pane above and press enter. Later we will see more about using the View and Filter boxes. }}
 
 
-You see that the "Status" of <code>test_deposit</code> is "not tested", and that the "Last executed" date is empty.
+You see that the '''Status''' of <code>test_deposit</code> is "not tested", and that the '''Last executed''' date is empty.
 
 To execute tests we use the "Run" button ( [[Image:debug-run-icon]] ) on the interface toolbar. The Run button will run all tests by default. However, there is a list of run options that you can access by clicking the black triangle just to the right of Run. You can choose to run all tests, only those with failing status, a filtered set of tests, or only those tests that you have selected in the tree below. We'll cover filtering a little later. For now, life is simple, we have only one test so just clicking the Run button should execute it. 
 
@@ -63,7 +63,7 @@ The test runs in background and the Eiffel Testing Framework interface now looks
 [[Image:Testing Framework interface after run 01]]
 
 
-It's pretty clear that our test has failed. Its status is now marked with the Failing icon ( [[Image:general-error-icon]] ) and in the box below the "Execution" tab we see that the status also includes a tag: <code>balance_increased</code>. To get a more detailed analysis, we can double-click the test in the "Tests" box. 
+It's pretty clear that our test has failed. Its status is now marked with the Failing icon ( [[Image:general-error-icon]] ) and in the box below the '''Execution''' tab we see that the status also includes a tag: <code>balance_increased</code>. To get a more detailed analysis, we can double-click the test in the '''Tests''' box. 
 
 
 [[Image:Testing Framework interface after run 02]]

documentation/current/eiffelstudio/eiffelstudio-guided-tour/using-autotest/managing-tests.wiki

@@ -86,16 +86,16 @@ These options are shortcuts to the various tag roots that we just discussed:
 #'''Types''' displays the sub-tree under the tag root '''type'''
 
 
-Any tagging system that you devise will also show up in the View box. Let's edit the manual test and add a second line of testing information with some tags that we just made up.
+Any tagging system that you devise will also show up in the View box. Let's edit our tests and add an additional line of testing information to each with some arbitrary hierarchical tags.
 
-So, now the entire test now looks like this:
+So, now the manual test now looks like this:
 
 <code>
     test_deposit_01
             -- New test routine
         note
             testing:  "covers/{BANK_ACCOUNT}.deposit"
-            testing:  "my_tag_1/my_tag_1_4/my_tag_1_4_2"
+            testing:  "my_tag_1/my_tag_1_1/my_tag_1_1_1"
         local
             l_ba: BANK_ACCOUNT
         do
@@ -104,6 +104,14 @@ So, now the entire test now looks like this:
         end
 </code>
 
+In the extracted test targeting <code>{BANK_ACCOUNT}.withdraw</code> this line has been added:
+<code>
+            testing: "my_tag_1/my_tag_1_1/my_tag_1_1_2"
+</code>
+and in the synthesized test which targets <code>{BANK_ACCOUNT}.withdraw</code> we add this line:
+<code>
+           testing: "my_tag_1/my_tag_1_2/my_tag_1_2_1"
+</code>
 As soon as we compile and look at the View box, we see that the root for our new tag shows up. And if we expand it completely, we find the test that we tagged.
 
 

documentation/current/eiffelstudio/eiffelstudio-guided-tour/using-autotest/testing-background-and-basics.wiki

@@ -65,8 +65,8 @@ Whenever you use the Eiffel Testing Framework, it will find your test classes, t
 
 There are three different types of tests supported by the Eiffel Testing Framework: 
 * Manual tests
-* Synthesized tests
 * Extracted tests 
+* Synthesized tests
 
 Each test of any of these types ultimately is a feature of class that inherits from EQA_TEST_SET. Ordinarily, though, the three types of tests won't be mixed in a test class. That is, any one particular test class will contain only one type of test. But from the point of view of the Eiffel Testing Framework, all types of tests are managed and run the same way. We will discuss these types of tests in more detail later, but for right now, let's just establish some definitions.   
 
@@ -79,6 +79,12 @@ Manual tests are features, procedures in fact, of classes that inherit from EQA_
 A manual test is "manual" in the sense that you code the essential procedural part of the test by hand. But you really don't have to deal with the more mundane business of creating the whole test class and ensuring the proper inheritance. The ''New Eiffel Test Wizard'' helps out by automatically creating the shell of a test class and the shell of a test for you to fill in. Then it's pretty easy to add new tests manually to an existing test class.
 
 
+{{definition|Extracted test|A test that has been created during the execution of a system as a result of a developer request or a failure of the system. Extracted with the test is the current runtime state. When run, the test will attempt to recreate the runtime context. }}
+
+
+Extracted tests are convenient because they allow you to accumulate tests that are based on actual failures of your software (good for the software, not so good for your ego!). Once these tests are in your suite of tests, they are available from then on.
+
+
 {{definition|Synthesized test|A test that is the product of generating and running a series of randomly generated invocations of target routines. }} 
 
 
@@ -87,11 +93,6 @@ The process of creating synthesized tests is sometimes known in the community as
 Synthesized tests are made possible by Design by Contract. Hopefully, you remember that one thing that DbC gives us is the handy ability to assign blame when something goes wrong. When a test makes a call to a routine we want to test, if a contract violation occurs, it may be the fault of the called routine or it may be the fault of the caller ... and that depends upon what type of contract violation has occurred. The contract violations that are interesting to the Eiffel Testing Framework in the process of synthesizing tests are only those in which the called routine is at fault. That is, postcondition and invariant violations. The Eiffel Testing Framework will then create a synthesized test for every ''unique'' failure in which the called routine being tested was to blame.  
 
 
-{{definition|Extracted test|A test that has been created during the execution of a system as a result of a developer request or a failure of the system. Extracted with the test is the current runtime state. When run, the test will attempt to recreate the runtime context. }}
-
-
-Extracted tests are convenient because they allow you to accumulate tests that are based on actual failures of your software (good for the software, not so good for your ego!). Once these tests are in your suite of tests, they are available from then on.
-
 
 ==Anatomy of a test==
 

documentation/current/eiffelstudio/eiffelstudio-guided-tour/using-autotest/using-generated-tests.wiki

@@ -65,7 +65,7 @@ In fact, if we try to synthesize tests on the class <code>BANK_ACCOUNT</code> in
 
 The important thing to notice here is the status: '''pass'''. There were no randomly generated cases that failed. So every valid invocation of a routine for class <code>BANK_ACCOUNT</code> completed satisfactorily. Therefore, no synthesized test class was created.
 
-If we re-introduce the bug into the <code>deposit</code> procedure of class <code>BANK_ACCOUNT</code> (i.e,. Remove this line of code: <code>balance := balance + an_amount</code>), and then request synthesized tests again, we get different results:
+If we re-introduce the bug into the <code>deposit</code> procedure of class <code>BANK_ACCOUNT</code> (i.e., Remove this line of code: <code>balance := balance + an_amount</code>), and then request synthesized tests again, we get different results:
 
 
 [[Image:Testing Framework synthesized results fail]]