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

[[Property:title|Create a manual test]]
[[Property:weight|2]]
[[Property:uuid|e78f25e3-ed3a-f8fa-e71d-28a4dda1825f]]
{{underconstruction}}


==A system to test==

For developing our manual test, let's use a simple system that contains a class modeling bank accounts. Here are two classes that will make up our system. The first, <code>APPLICATION</code> will be the root class of our system. <code>APPLICATION</code> really only serves to declare an attribute of type <code>BANK_ACCOUNT</code>, which is the class we will write a test against. <code>APPLICATION</code> looks like this:

<code>
class
    APPLICATION

inherit
    ARGUMENTS

create
    make

feature {NONE} -- Initialization

    make
            -- Run application.
        do
        end

    my_account: BANK_ACCOUNT

end
</code>


And here's the class <code>BANK_ACCOUNT</code>:

<code>
class
    BANK_ACCOUNT
inherit
    ANY
        redefine
            default_create
        end
feature
    default_create
        do
            balance := 0
        end

    balance: INTEGER

    deposit (an_amount: INTEGER)
            -- Deposit `an_amount'.
        require
            amount_large_enough: an_amount > 0
        do
        ensure
            balance_increased: balance > old balance
            deposited: balance = old balance + an_amount
        end

    withdraw (an_amount: INTEGER)
            -- Withdraw `an_amount'.
        require
            amount_large_enough: an_amount > 0
            amount_valid: balance >= an_amount
        do
            balance := balance - an_amount
        ensure
            balance_decreased: balance < old balance
            withdrawn: balance = old balance + an_amount
        end

invariant
    balance_not_negative: balance >= 0
end
</code>

You shouldn't let it worry you if you've noticed that the class <code>BANK_ACCOUNT</code> contains some flaws. We'll deal with these later.

If you want to work along with this tutorial, you should be able to copy the text of each these classes from this page and paste it into the EiffelStudio editor pane. Build a system using these two classes, and <code>{APPLICATION}.make</code> as the root.


{{note|If you are using EiffelStudio version 6.3, there two things you will need to do to prepare your system for use with the Eiffel Testing Framework. Both of these are done from the [[EiffelStudio: Project settings window]].<br/> 1) Set your project to be a console application in the [[Advanced options]].<br/>2) Set a value of <code>False</code> for the <code>Recursive</code> attribute of your project cluster in [[Group options]].}}

==Getting to the Eiffel Testing Framework interface==

If the Eiffel Testing Framework interface is not on a tab next to Clusters, Features, and Favorites, you can invoke it by following the menu path:
<code lang=text>
View --> Tools --> Testing Tool
</code>
Depending upon your version and platform, the Eiffel Testing Framework interface should look about like this:


[[Image:empty testing tool 01]]


==Creating a new test==

To begin the process of creating a new test, click the Create New Tests button ( [[Image:create new tests]] ) on the interface's tool bar. 

This will launch the New Eiffel Test Wizard which guides you through the test creation process.

If this is the first time you've used the testing tool for this project, it is likely that you will be presented with a dialog box asking if you want to add the testing library classes to your project and recompile:


[[Image:add testing libraries dialog]]

You want EiffelStudio to do this before launching the wizard so, click "Yes". In a moment your system will have recompiled with the testing library classes available. Remember that you won't need to interact much with the testing classes, but the Eiffel Testing Framework uses them, so they need to be available. As long as the testing classes stay available, you should not see this dialog again for the current project.


==The New Eiffel Test Wizard==

After the compile completes, then the first pane of the New Eiffel Test Wizard appears. It should look like this:


[[Image:New test wizard screen 01 01]]


As you can see, there is a radio button for each of the three types of tests that were discussed in [[Testing: Background and basics]]. The buttons for '''Manual''' and '''Synthesized''' tests are enabled. The button for '''Extracted''' tests is not sensitive because the extraction of tests is only valid during the time in which a system is actually running. That's okay, we were going to choose '''Manual''' anyway.

If we select '''Manual''' and click '''Next''', then second pane of the wizard appears:


[[Image:New test wizard screen 02M 01]]


We will use this wizard pane to name our test class and let the Eiffel Testing Framework 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 the Eiffel Testing Framework 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. 

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:


[[Image:New test wizard add cluster 01]]


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>bank_account</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: 


[[Image:New test wizard screen 02M 02]]


We're ready to click '''Next''', but before we do, let's look at the check boxes on this wizard pane. The two check boxes labeled '''Redefine `on_prepare'''' and '''Redefine `on_clean'''' have to do with the way that tests are run. 

The Eiffel Testing Framework runs each test as a three step process:
# Preparation
# Execution
# Clean up

There are features in class <code>EQA_TEST_SET</code> named <code>prepare</code> and <code>clean</code> which accomplish steps 1 and 3 above. These features are <code>frozen</code>, therefore you cannot redefine them in a test class (i.e., a descendant of <code>EQA_TEST_SET</code>) However the class does provide features that can be redefined so that you can include custom behavior before and/or after the execution of a test. These features are <code>on_prepare</code> and <code>on_clean</code>. So if you check one of these boxes, then the test class that is built for you will include a redefined feature ready for you to implement. In this simple example, we'll leave both boxes unchecked. 


{{note|The check box labeled '''System level test''' is displayed here as not sensitive. This box is reserved for future system level testing capability in the Eiffel Testing Framework, so for versions including 6.4, you can ignore it. }}


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:


[[Image:New test wizard screen 03M 01]]


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>.


==About Tags==

The other thing that can be done on this pane is to associate our test with any Eiffel Testing Framework '''tags''' that we feel are appropriate. 

'''Tags''' are simply names or otherwise meaningful strings of characters that are arranged hierarchically and can be associated with a test to help manage, maintain, execute, and monitor its results. Any one test can support many tags. It is quite likely that during the development process, your system may eventually accumulate a great number of tests. And you may want only to execute some selected portion of those tests at any particular time. '''Tags''' allow you do that with the help of the Eiffel Testing Framework.

One of the most common types of tags specifies what class and feature a test covers. In our example, we will write our test against the <code>deposit</code> procedure of the class <code>BANK_ACCOUNT</code>. As you will see in a moment, the tag that will express this is:
<code>
covers/{BANK_ACCOUNT}.deposit
</code>
When we look at a tag in this notation, each hierarchical level is delimited by the forward slash. So the tag above specifies a root "covers" and its child "{BANK_ACCOUNT}.deposit". If this same test tested both <code>deposit</code> and <code>withdraw</code>, then its list of tags would be:
<code>
covers/{BANK_ACCOUNT}.deposit
covers/{BANK_ACCOUNT}.withdraw
</code>
So when every you asked to view or run all the tests that <code>covers</code> either <code>deposit</code> or <code>withdraw</code>, this test would show up in that set. 
The "covers" tags, as you will see, can be generated by the Eiffel Testing Framework when you create a test. But tags can be completely arbitrary, too. So, for example if you were building software that you expected to run on multiple platforms, in the test suite, you might have a test with the following tags:
<code>
platform/os/linux
platform/architecture/i386
</code>
So this test would be specifically for Linux running on Intel architecture. When you were testing on that platform combination, you could select the appropriate tests to run using tags.


==Associating tags with a new test==

Now that we've named our new test, let's associate a tag with it that indicates that it <code>covers</code> the <code>deposit</code> procedure of class <code>BANK_ACCOUNT</code>. Looking again at the New Eiffel test wizard pane, you will see that there are three boxes under the label '''Tags for new tests'''. The first is just a display of the list of tags that you have added to the new test. The next box down allows you to add an arbitrary tag sequence like:
<code>
platform/os/linux
</code>
And the third allows you to add certain commonly used or predefined tag types. This is the box we'll use. So first we will select '''Add class/feature under test tag''', then click the '''Add''' button to the right of the box. This will cause the appearance of a dialog that allows us to pick a target class and routine from our system. So we navigate to <code>{BANK_ACCOUNT}.deposit</code>. The dialog will look like this:


[[Image: New test wizard screen 03M dialog 01]]


Now we click '''OK'''. The dialog disappears and the <code>covers</code> tag:
<code>
covers/{BANK_ACCOUNT}.deposit
</code>
is now visible in the list of tags for the new test we are creating. So, next click '''Create''' and the wizard pane disappears and the Eiffel Testing Framework will create our test class and display it in the edit window.


==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 an Eiffel Testing Framework manual test.

Next let's see what it takes to execute a test.