mirrors/eiffel-org
1
0
Fork 0
mirror of https://github.com/EiffelSoftware/eiffel-org.git synced 2025-12-07 23:32:42 +01:00
Code Issues Packages Projects Releases Wiki Activity

Update wikipage Create a manual test. (Signed-off-by:jocelyn).

Browse Source 
git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@1459 abb3cda0-5349-4a8f-a601-0c33ac3a8c38
This commit is contained in:
eiffel-org
2015-11-24 09:08:43 +00:00
parent 867e41afd5
commit 7ee4a92b0c
1 changed files with 323 additions and 323 deletions
Download Patch File Download Diff File Expand all files Collapse all files

646
documentation/trunk/eiffelstudio/Tutorials/using-autotest/create-manual-test.wiki
View File

@@ -1,323 +1,323 @@
[[Property:title|Create a manual test]] [[Property:title|Create a manual test]]
[[Property:weight|2]] [[Property:weight|2]]
[[Property:uuid|e78f25e3-ed3a-f8fa-e71d-28a4dda1825f]] [[Property:uuid|32273F6B-AA84-475F-86B8-143F212FB40E]]
==A system to 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, <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: 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> <code>
class class
APPLICATION APPLICATION
inherit inherit
ARGUMENTS ARGUMENTS
create create
make make
feature {NONE} -- Initialization feature {NONE} -- Initialization
make make
-- Run application. -- Run application.
do do
create my_account create my_account
end end
my_account: BANK_ACCOUNT my_account: BANK_ACCOUNT
end end
</code> </code>
And here's the class <code>BANK_ACCOUNT</code>: And here's the class <code>BANK_ACCOUNT</code>:
<code> <code>
class class
BANK_ACCOUNT BANK_ACCOUNT
inherit inherit
ANY ANY
redefine redefine
default_create default_create
end end
feature feature
default_create default_create
do do
balance := 0 balance := 0
end end
balance: INTEGER balance: INTEGER
deposit (an_amount: INTEGER) deposit (an_amount: INTEGER)
-- Deposit `an_amount'. -- Deposit `an_amount'.
require require
amount_large_enough: an_amount > 0 amount_large_enough: an_amount > 0
do do
ensure ensure
balance_increased: balance > old balance balance_increased: balance > old balance
deposited: balance = old balance + an_amount deposited: balance = old balance + an_amount
end end
withdraw (an_amount: INTEGER) withdraw (an_amount: INTEGER)
-- Withdraw `an_amount'. -- Withdraw `an_amount'.
require require
amount_large_enough: an_amount > 0 amount_large_enough: an_amount > 0
amount_valid: balance >= an_amount amount_valid: balance >= an_amount
do do
balance := balance - an_amount balance := balance - an_amount
ensure ensure
balance_decreased: balance < old balance balance_decreased: balance < old balance
withdrawn: balance = old balance + an_amount withdrawn: balance = old balance + an_amount
end end
invariant invariant
balance_not_negative: balance >= 0 balance_not_negative: balance >= 0
end end
</code> </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. 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. 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 AutoTest. 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]].}} {{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]].<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 AutoTest interface== ==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: If the AutoTest interface is not on a tab next to Clusters, Features, and Favorites, you can invoke it by following the menu path:
<code lang=text> <code lang=text>
View --> Tools --> AutoTest View --> Tools --> AutoTest
</code> </code>
Depending upon your version and platform, the AutoTest interface should look about like this: Depending upon your version and platform, the AutoTest interface should look about like this:
[[Image:AutoTest empty tool 01]] [[Image:AutoTest empty tool 01]]
==Creating a new test== ==Creating a new test==
To begin the process of creating a new test, click the Create New Test button ( [[Image:create new tests]] ) 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: To begin the process of creating a new test, click the Create New Test button ( [[Image:create new tests]] ) 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:
[[Image: AutoTest create new test|Create new test drop-down menu]] [[Image:AutoTest create new test|Create new test drop-down menu]]
For now, let's select Create Manual Test. 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: 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:AutoTest add testing libraries dialog]] [[Image:AutoTest 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 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. 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== ==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: 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:
[[Image:AutoTest Manual Test pane]] [[Image:AutoTest Manual Test pane]]
Here we will name our test. Let's say that we plan to write this test against the feature <code>{BANK_ACCOUNT}.deposit</code>. We'll give this test the name <code>test_deposit_01</code>. The name uses an ad hoc naming convention for tests. You can use this, or develop your own. The prefix <code>test_</code> comes before the feature name it will test, and the suffix <code>_01</code> follows, 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>. Here we will name our test. Let's say that we plan to write this test against the feature <code>{BANK_ACCOUNT}.deposit</code>. We'll give this test the name <code>test_deposit_01</code>. The name uses an ad hoc naming convention for tests. You can use this, or develop your own. The prefix <code>test_</code> comes before the feature name it will test, and the suffix <code>_01</code> follows, 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>.
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. 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: AutoTest runs each test as a three step process:
# Preparation # Preparation
# Execution # Execution
# Clean up # 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. 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 AutoTest, so for versions including 7.0, you can ignore it. }} {{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. 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. 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== ==The Tags Pane==
[[Image:AutoTest Tags pane empty|Tags pane]] [[Image:AutoTest Tags pane empty|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|About Tags]] below. 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|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. 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.
[[Image:Autotest test coverage tag dialog|Dialog for coverage tag]] [[Image:Autotest test coverage tag dialog|Dialog for coverage tag]]
We'll choose class <code>BANK_ACCOUNT</code> and feature <code>deposit</code>, click '''OK'''. We'll choose class <code>BANK_ACCOUNT</code> and feature <code>deposit</code>, click '''OK'''.
Now you should see the coverage tag in the list of '''Tags used in new test'''. Now you should see the coverage tag in the list of '''Tags used in new test'''.
[[Image: AutoTest Tags pane|Tags pane]] [[Image:AutoTest Tags pane|Tags pane]]
That takes care of adding our coverage tag, so let's click '''Next''' to go to the next wizard pane, the '''General''' pane. 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== ==The General Pane==
[[Image: AutoTest General pane empty|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>. 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. 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. 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. 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'''. 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: 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 Add Cluster dialog]] [[Image:AutoTest Add Cluster dialog]]
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: 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 General pane]] [[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. 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. So, now we click '''Launch''', and AutoTest creates our test set and test.
==Writing a test== ==Writing a test==
Let's look at the class <code>TEST_BANK_ACCOUNT</code>: Let's look at the class <code>TEST_BANK_ACCOUNT</code>:
<code> <code>
note note
description: "[ description: "[
Eiffel tests that can be executed by testing tool. Eiffel tests that can be executed by testing tool.
]" ]"
author: "EiffelStudio test wizard" author: "EiffelStudio test wizard"
date: "$Date$" date: "$Date$"
revision: "$Revision$" revision: "$Revision$"
testing: "type/manual" testing: "type/manual"
class class
TEST_BANK_ACCOUNT TEST_BANK_ACCOUNT
inherit inherit
EQA_TEST_SET EQA_TEST_SET
feature -- Test routines feature -- Test routines
test_deposit_01 test_deposit_01
-- New test routine -- New test routine
note note
testing: "covers/{BANK_ACCOUNT}.deposit" testing: "covers/{BANK_ACCOUNT}.deposit"
do do
assert ("not_implemented", False) assert ("not_implemented", False)
end end
end end
</code> </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. 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: So, <code>test_deposit_01</code> now looks like this:
<code> <code>
test_deposit_01 test_deposit_01
-- New test routine -- New test routine
note note
testing: "covers/{BANK_ACCOUNT}.deposit" testing: "covers/{BANK_ACCOUNT}.deposit"
local local
l_ba: BANK_ACCOUNT l_ba: BANK_ACCOUNT
do do
create l_ba create l_ba
l_ba.deposit (500) l_ba.deposit (500)
end end
</code> </code>
Now we have created and written a manual test using AutoTest. 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. 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== ==About Tags==
The '''Tags''' pane allows us to associate our test with any AutoTest '''tags''' that we feel are appropriate. 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. '''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 <code>deposit</code> procedure of the class <code>BANK_ACCOUNT</code>. The tag that we added to express this is: 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 <code>deposit</code> procedure of the class <code>BANK_ACCOUNT</code>. The tag that we added to express this is:
<code> <code>
covers/{BANK_ACCOUNT}.deposit covers/{BANK_ACCOUNT}.deposit
</code> </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: 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> <code>
covers/{BANK_ACCOUNT}.deposit covers/{BANK_ACCOUNT}.deposit
covers/{BANK_ACCOUNT}.withdraw covers/{BANK_ACCOUNT}.withdraw
</code> </code>
So when ever you ask 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. So when ever you ask 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 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 <code>BANK_ACCOUNT</code>, you could manually add a tag that expresses that, i.e., a "covers" tag for <code>BANK_ACCOUNT</code> that does not specify a particular routine: 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 <code>BANK_ACCOUNT</code>, you could manually add a tag that expresses that, i.e., a "covers" tag for <code>BANK_ACCOUNT</code> that does not specify a particular routine:
<code> <code>
covers/{BANK_ACCOUNT} covers/{BANK_ACCOUNT}
</code> </code>
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: 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> <code>
platform/os/linux platform/os/linux
platform/architecture/i386 platform/architecture/i386
</code> </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. 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=== ===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: 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:
<code> <code>
platform/os/linux platform/os/linux
</code> </code>
Below that box 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 <code>{BANK_ACCOUNT}.deposit</code>. Below 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 <code>{BANK_ACCOUNT}.deposit</code>.
===Other predefined tags=== ===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'''. 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: Selecting '''Run test in private evaluator''' will insert the tag:
<code> <code>
execution/isolated execution/isolated
</code> </code>
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 effect 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. 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: If you select '''Run test serially''', the following tag will be inserted:
<code> <code>
execution/serial execution/serial
</code> </code>
Tests tagged with this tag will not run concurrently with any other similarly tagged test is running. 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: 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:
<code> <code>
execution/serial/group_1 execution/serial/group_1
</code> </code>
and some are tagged: and some are tagged:
<code> <code>
execution/serial/group_2 execution/serial/group_2
</code> </code>
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>. 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>.