Create a manual test

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, APPLICATION will be the root class of our system. APPLICATION really only serves to declare an attribute of type BANK_ACCOUNT, which is the class we will write a test against. APPLICATION looks like this:

class APPLICATION inherit ARGUMENTS create make feature {NONE} -- Initialization make -- Run application. do create my_account end my_account: BANK_ACCOUNT end

And here's the class BANK_ACCOUNT:

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

You shouldn't let it worry you if you've noticed that the class BANK_ACCOUNT 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 {APPLICATION}.make 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 AutoTest. Both of these are done from the EiffelStudio: Project settings window.
1) Set your project to be a console application in the Advanced options.
2) Set a value of False for the Recursive attribute of your project cluster in Group options.

Getting to the AutoTest interface

If the AutoTest interface is not on a tab next to Clusters, Features, and Favorites, you can invoke it by following the menu path: View --> Tools --> AutoTest Depending upon your version and platform, the AutoTest interface should look about like this:

Creating a new test

To begin the process of creating a new test, click the Create New Test button ( ) on the interface's tool bar. When you click this button, by default AutoTest will set you up to create a new Manual test. To choose a different test type, click the small triangle to the right of the Create New Test button and you'll be presented with a drop-down menu of choices:

For now, let's select Create Manual Test.

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:

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 AutoTest 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 Manual Test Pane

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

Here we will name our test. Let's say that we plan to write this test against the feature {BANK_ACCOUNT}.deposit. We'll give this test the name test_deposit_01. The name uses an ad hoc naming convention for tests. You can use this, or develop your own. The prefix test_ comes before the feature name it will test, and the suffix _01 follows, so that we have a framework for adding more tests against deposit. 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, test_deposit_very_large_amount.

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.

AutoTest runs each test as a three step process:

1. Preparation
2. Execution
3. Clean up

There are features in class EQA_TEST_SET named prepare and clean which accomplish steps 1 and 3 above. These features are frozen, therefore you cannot redefine them in a test class (i.e., a descendant of EQA_TEST_SET) 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 on_prepare and on_clean. 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 AutoTest, so for versions including 7.0, you can ignore it.

Another thing to notice before we click Next, is that at this point we could click Launch. Launch will immediately try to create the test with the information it has available. The idea is that if you are creating several similar tests, you can change the test routine name and leave the rest of the information as you had entered it on a previous test. This keeps you from having to traverse the wizard panes entering the same information repeatedly.

But in our case, we need to use the subsequent wizard panes, so let's click Next, to go to the next one.

The Tags Pane

With this pane, you identify tags for your test that allow you to manage your test set more easily in the future. Read more in About Tags below.

For this test, we will include only a tag that identifies the class and feature covered by the test. To do this we click Add tag for covered class/feature. When we do, we are presented with a dialog in which we can choose a class and feature.

We'll choose class BANK_ACCOUNT and feature deposit, click OK.

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.

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 TEST_. So in our case, we want to build a test against a feature of the BANK_ACCOUNT class, so we will name our test class TEST_BANK_ACCOUNT.

Now, for the question of where the tests should be kept.

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 APPLICATION and BANK_ACCOUNT 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:

We can name our test cluster tests, the default, and make it a subcluster to our root cluster accounts. 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:

At this point we have provided all the information necessary for AutoTest to create the shell for a manual test on the deposit feature of the BANK_ACCOUNT class.

So, now we click Launch, and AutoTest creates our test set and test.

Writing a test

Let's look at the class TEST_BANK_ACCOUNT:

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

We can see that the feature test_deposit_01 exists, but doesn't really test anything. So, let's change that. We'll alter test_deposit_01 so that it creates an instance of BANK_ACCOUNT and then makes a deposit to that account.

So, test_deposit_01 now looks like this:

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

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

The Tags pane allows us to associate our test with any AutoTest 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 AutoTest.

One of the most common types of tags specifies what class and feature a test covers. In our example, we wrote our test against the deposit procedure of the class BANK_ACCOUNT. The tag that we added to express this is:covers/{BANK_ACCOUNT}.depositWhen 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 deposit and withdraw, then its list of tags would be:covers/{BANK_ACCOUNT}.deposit covers/{BANK_ACCOUNT}.withdrawSo when ever you ask to view or run all the tests that covers either deposit or withdraw, this test would show up in that set.

The "covers" tags, as you saw earlier, can be generated by AutoTest's New Eiffel Test Wizard when you create a new test. But you could enter the tag manually, as well. For example if you had written a high-level test that exercised all or most of the functionality of the class BANK_ACCOUNT, you could manually add a tag that expresses that, i.e., a "covers" tag for BANK_ACCOUNT that does not specify a particular routine:covers/{BANK_ACCOUNT}

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:platform/os/linux platform/architecture/i386So 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

Looking again at the Tags pane, you will see that there are two boxes under the label Tags used in new test. 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:platform/os/linuxBelow that box, there are links that allow you to add certain commonly used or predefined tag types. One of these, Add tag for covered class/feature is the link we used to add the "covers" tag for our test on {BANK_ACCOUNT}.deposit.

Other predefined tags

In addition to Add tag for covered class/feature, choices for other predefined tags are shown as links. For example, Add tag to run test in private evaluator and Add tag to run test serially.

Selecting Run test in private evaluator will insert the tag:execution/isolated

When tests are executed, they do so within the context of evaluator processes. Normally, evaluator processes are reused for multiple test executions. But if you select Run in private evaluator, the tag added to your test guarantees that this test will be run in a fresh evaluator process, that terminates when the test completes. This can be helpful, for example, when you don't want your test to enter or leave the evaluator process with the effects of "once" routines or any other action that might affect the efficacy of other tests. For example, if your test executes external routines which might have a damaging effect on memory, you should run the test in a private evaluator.

If you select Run test serially, the following tag will be inserted:execution/serial

Tests tagged with this tag will not run concurrently with any other similarly tagged test is running.

You can extend the serial execution tag with arbitrary terms that will differentiate groups of tagged tests. For example, if some of your tests are tagged like this:execution/serial/group_1and some are tagged:execution/serial/group_2then AutoTest will not run any group_1 tagged test concurrently with any other group_1 test, and likewise for tests tagged group_2.