mirrors/eiffel-org
1
0
Fork 0
mirror of https://github.com/EiffelSoftware/eiffel-org.git synced 2025-12-06 14:52:03 +01:00
Code Issues Packages Projects Releases Wiki Activity

Author:halw

Browse Source 
Date:2009-02-20T16:54:39.000000Z


git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@190 abb3cda0-5349-4a8f-a601-0c33ac3a8c38
This commit is contained in:
halw
2009-02-20 16:54:39 +00:00
parent a43a276955
commit 88339133dd
2 changed files with 20 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
documentation/current/eiffelstudio/eiffelstudio-guided-tour/using-autotest/using-extracted-tests.wiki
View File

@@ -10,12 +10,12 @@ At any time that you are running a system in EiffelStudio debugger and your syst
The value of extracted tests is that they provide a kind of a snapshot in testing form that will reproduce the unexpected failure. An extracted test attempts to reproduce the context in which the offending routine executed. So, extracted tests supplement your manual tests. They serve to cover situations which you just may not have written manual tests to cover.
So, extracted tests are intended to supplement the suite of manual tests that you have created, by covering situations that you had not anticipated.
Extracted tests are intended to supplement the suite of manual tests that you have created to do the bulk of your testing. So, usually when you create an extracted test, it happens as a result of your being surprised. You will notice that each time you create an extracted test, you get a new test class, too. This is in contrast to manual tests, in which you might use the wizard to create a new test class and one new test to cover a particular target class and target routine. Then you might manually create, in that same test class, many additional tests covering the routine behavior of the same or other target routines in the same target class.
==Creating a extracted test==
Let's use the same test system we used for manual tests to demonstrate the creation of an extracted test.
Let's use the same test system we used for manual tests to demonstrate the creation of an extracted test. The example will be slightly lame because it will find a problem that certainly we would already have discovered had we written a comprehensive set of manual tests against the <code>BANK_ACCOUNT</code> class. Still, the simplicity should help keep things clear.
If you remember, the root class for the example application, contained no instructions, just a root procedure with no instructions and a declaration <code>my_account</code> of type <code>BANK_ACCOUNT</code>:

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

@@ -2,16 +2,30 @@
[[Property:link_title|Using generated tests]]
[[Property:weight|7]]
[[Property:uuid|c17ebddf-5d35-76c1-4912-d9f1ca3770a5]]
{{underconstruction}}
==About synthesized tests==
Synthesized tests fill a different role from either extracted or manual tests. The idea behind synthesized tests is that because we specify software through its contracts, and because compliance of the software to those contracts can be actively monitored at runtime, we can know two things necessary for building tests:
#For any routine, what argument values are valid
#For the execution of any routine, what are the acceptable results
The first bit of knowledge comes from the ''preconditions'' of target routines. The second comes from ''postconditions'' of target routines and the ''invariants'' of target classes. Armed with this knowledge, we should be able to generate a series of invocations target routines using random (but valid) argument values, and evaluate the results. This is what is done by an internal facility of the Eiffel Testing Framework that builds synthesized tests (this facility is often referred to as AutoTest). After many of these randomly generated invocations, the Eiffel Testing Facility attempts to synthesize the results of these feature calls into new test classes. The tests in these new test classes contain the calls leading up and including calls that fail.
You may look at a synthesized test class and think that it seems to be very long and to contain lots of stuff that you doubt is relevant. This is a fair assessment. The processes that the Eiffel Testing Framework uses to build synthesized tests are constantly being improved. But for now, synthesized tests, although useful, are not always things of extraordinary beauty.
So for the time being, unlike manual and extracted tests, you should not make synthesized tests a part of your permanent test suite. Rather, you should consider them a disposable means to an end. Use each synthesized tests as a guide for building an effective and readable manual test.
==Creating synthesized tests==
If you've been through the creation of manual and extracted tests, then it should come as no surprise to learn that you use the '''New Eiffel test wizard''' to create synthesized tests. And much of this process will seem familiar now.
In the first pane, choose the radio button labeled '''Synthesized test using AutoTest'''. Then click '''Next'''.
The second pane asks you to provide a class name for the new test class and designate a cluster for it. In the case of synthesized tests, the class name you enter is actually a prefix, that will have a unique number appended to it.