EiffelStudio: an EiffelSoftware project - User contributions [en]

EiffelOnMac

2009-09-14T20:45:01Z

Roederja: /* Using MacPorts */

[[Category:EiffelStudio]]
[[Category:Macintosh]]

This page gives you an overview about how to get EiffelStudio running on your Mac.

== Installation ==

=== Using binary packages ===

{{Warning|This method does not work at the moment. Please install EiffelStudio using MacPorts.<br/>See [[Talk:EiffelOnMac|Discussion]] for more information.}}

# Install the latest version of [http://xquartz.macosforge.org/trac/wiki/WikiStart XQuartz]: [http://xquartz.macosforge.org/downloads/X11-2.4.0.dmg download]
# Install the EiffelStudio 6.4 Mac package: [http://dfurrer.com/files/eiffelstudio64.dmg download]

=== Using MacPorts ===
The port should work on Mac OS X 10.4 and later.

MacPorts is a great tool that allows you to use many Unix applications on the Mac. We have created a package in the MacPorts repository that allows you to to install Eiffel Studio with all dependencies in a convenient way. First, install MacPorts as described [http://trac.macosforge.org/projects/macports/wiki/InstallingMacPorts here].

Now simply type:
<pre>
sudo port install eiffelstudio64
</pre>
and you're ready to go (after a few hours compiling that is :)). Compiling on a new Intel Mac reportedly takes about an hour. An old 800 MHz PowerPC takes about seven hours.

A fairly recent development package is available under the name eiffelstudio65. (Both packages can be installed simultaneously)

When a new version of EiffelStudio becomes available, you can upgrade like so:
<pre>
sudo port selfupdate
sudo port upgrade eiffelstudio65
</pre>

The installer from the previous subsection is actually created using MacPorts as well using the mpkg command. For more information take a look at the [http://guide.macports.org MacPorts Guide]

== Starting EiffelStudio ==

Simply navigate to /Applications/MacPorts/Eiffel<nn> and double click the EiffelStudio icon.

Alternatively, you can also start EiffelStudio from the command line by entering the command 'estudio' or use the command-line eiffel compiler 'ec'.

== FAQ ==
====I get a crash with a Permission denied: Operating system error, how do I fix it?====

Delete the .ec directory in your home directory.

====I get an error with precompiles, why is that ?====

Precompiles did not work on the Mac before EiffelStudio 6.4 due to a limitation of the linker. To work around this issue you have to disable the precompiles with those versions.

{{Note|When you create a project, EiffelStudio will ask if you want to perform precompiles – say no. Then disable the precompiles for this project through the Project>Project menu. In the 'Groups>Precompile' section, remove all precompiles (eg., base_pre). Select the 'base_pre' precompile and click the red cross delete tool at the top of the window.}}

{{Note|Precompiling the Eiffel libraries after installing the Port is possible, there are security policies to take into account. The Port installs EiffelStudio under the system's ''/Application/MacPorts'' directory and '''not''' the user ''~/Application/MacPorts''. Due of this, EiffelStudio must be run as a super user and the precompiles build using the '''Tools''' > '''Precompile Wizard''' option. Alternatively, alter the base installation path when requesting to install the Port.}}

=== How can I make EiffelStudio on the Mac look nicer? ===
* Use the gtk clearlooks theme from MacPorts (packages gtk2-clearlooks and gtk-theme-switch, then run 'switch2')
=== Typing ec or estudio on the command line doesn't work ===
To run the '''ec''' compiler from your shell, set up variables similar to these (e.g. in ~/.profile):
<pre>
# Setting variables for EiffelStudio.
export ISE_EIFFEL=/Applications/MacPorts/Eiffel64
export ISE_PLATFORM=macosx-ppc (or macosx-x86)
export ISE_PROJECTS=$HOME
export ES_PATH=$ISE_EIFFEL/studio/spec/$ISE_PLATFORM/bin
export PATH=$ES_PATH:$PATH
</pre>

==Hints==
* Pick and Drop works with Apple-key + mouse click.
* To set up the correct (default) browsers use "open" as your command-line browser in Tools>Preferences...
* The F10 and F11 debugging shortcuts conflict with the standard Exposé keys. Here are some workarounds:
** Use the toolbar instead.
** Reassign these shortcuts in EiffelStudio (Tools>Preferences).
** Reassign the Exposé keys in System Preferences.
* The version of '''X11 installed with Mac OS X Leopard 10.5.0 and 10.5.1 does not work'''. The 10.5.2 and later updates are probably ok, however, but if you're having problems have a look at http://trac.macosforge.org/projects/xquartz. For more details, see http://www.eiffelroom.com/blog/paulbates/a_little_help_for_mac_users which pre-dates the release of 10.5.2.

EiffelOnMac

2009-04-01T09:00:07Z

Roederja: /* Working around firewall issues */

[[Category:EiffelStudio]]
[[Category:Macintosh]]

This page gives you an overview about how to get EiffelStudio running on your Mac.

== Installation using MacPorts ==

The officially supported versions of Mac OS X are 10.4 and 10.5.

MacPorts is a great tool that allows you to use many Unix applications on the Mac. We have created a package in the MacPorts repository that allows you to to install a fairly recent build with all dependencies in a convenient way. Install MacPorts as described [http://trac.macosforge.org/projects/macports/wiki/InstallingMacPorts here]. This might add the line 'export DISPLAY=:0.0' to your .profile (or .bashrc) file. This is valid for Tiger, but will prevent EiffelStudio launching in Leopard. Make sure this line is deleted if using Leopard. For more information consult the [http://guide.macports.org/ MacPorts guide] (which seems to be more up-to-date).

Now simply type:
<pre>
sudo port install eiffelstudio
</pre>
and you're ready to go (after a few hours compiling that is :)). Compiling on a new Intel Mac reportedly takes about an hour. An old 800 MHz PowerPC takes about seven hours.

The latest development build is available in the eiffelstudio-devel port. To install it type:
<pre>
sudo port install eiffelstudio-devel
</pre>
It can be installed alongside the regular ES build.

'''Note:''' Precompiles do not work well on the Mac. If you still want to give it a shot, you need to precompile the '''base''' and '''vision2''' libraries once with admin rights. To do that, you can type: "sudo estudio" in an xterm window and then use the precompilation wizard (Tools>Precompilation wizard) or simply create a new project that will be precompiled. On Mac OS 10.5 (Leopard) this doesn't seem to work anymore. Here you need to set the permissions of the precompile folder to world writeable (or at least writeable for your current user). To do this type chmod a+w $ISE_EIFFEL/precomp. You can change it back after completing the precompilation: chmod 755 $ISE_EIFFEL/precomp.

== Starting EiffelStudio ==

Simply navigate to /Applications/MacPorts/Eiffel<nn> and double click the EiffelStudio icon. This will automatically start X11.

Alternatively, you can also start EiffelStudio from X11 by simply entering the command 'estudio'. You can also 'sudo estudio', but the sudo does not seem to ever be needed even with a standard (non-admin) usercode (and you do use a standard usercode right? Admin usercodes are bad, can corrupt things, allow hackers (total count so far 0) more access. Also your users might not be running admin, so you should run standard and test under standard. Another tip – don't call your admin usercode 'admin'.)

== Disable Precompiles ==

For some reason (ask the Eiffel For Mac guys), precompiles for 6.2 don't work on the Mac. When you create a project, EiffelStudio will ask if you want to perform precompiles – say no. You must then disable the precompiles. Do this from the Project>Project Settings menu. Under the 'Groups>Precompile' section, remove all precompiles (eg., base_pre). Select the 'base_pre' precompile and click the red cross delete tool at the top of the window.

If you are not using EiffelStudio, you can delete the precompile lines in the projects .ecf file (eg., <precompile name="base_pre" location="$ISE_PRECOMP/base.ecf"/>)

{{Note|Precompiling the Eiffel libraries after installing the Port is possible, there are security policies to take into account. The Port installs EiffelStudio under the system's ''/Application/MacPorts'' directory and '''not''' the user ''~/Application/MacPorts''. Due of this, EiffelStudio must be run as a super user and the precompiles build using the '''Tools''' > '''Precompile Wizard''' option. Alternatively, alter the base installation path when requesting to install the Port.}}

== Upgrading ==

When a new version of EiffelStudio is available, you can upgrade like so:
<pre>
sudo port selfupdate
sudo port upgrade eiffelstudio
</pre>

Be prepared for another long wait while it compiles. You can do likewise for eiffelstudio-devel, of course.

Beware that this may not get the latest release if [http://trac.macports.org/browser/trunk/dports/lang/eiffelstudio/Portfile the Port file] has not been updated yet. Even after it has been updated, it may take a week for it to propagate to MacPorts. If you can't wait, here's how to get the latest version immediately:
# Edit your local copy of the Portfile: '''sudo port edit eiffelstudio'''. Change '''minor_version''' and '''version'''. Save.
# Tell MacPorts to use the local copy of your Portfile: '''cd /opt/local/var/macports/sources/rsync.macports.org/release/ports''' (assuming this is where your ports are), then type '''portindex'''. It will print hundreds of "Adding port" messages, one of which should be lang/eiffelstudio.
# Find out the checksums for the new version: '''sudo port -d upgrade eiffelstudio'''.
# Edit your local Portfile again, substituting the checksums.
# Now '''sudo port upgrade eiffelstudio''' should upgrade to the version described in your local Portfile.

== Working around firewall issues ==
If you can't use the MacPorts rsync repository due to your firewall you can check out the macports source tree via SVN. To do this open a Terminal window and cd to a directory where you want your ports tree to live. Then type:
<pre>
svn co http://svn.macports.org/repository/macports/trunk/dports/
</pre>
After the command has finished open the file /opt/local/etc/macports/sources.conf in your favorite text editor. Comment out the rsync URL and add a file URL that points to the dports directory that you just checked out from the SVN repository. Your sources.conf file will then look something like that:
<pre>
# To get macports from the macports rsync server use:
# rsync://rsync.macports.org/release/ports/

file:///Volumes/Data/SVN/macports/dports [default]
</pre>

Note: The above steps only work when you have an SVN client installed. This is a bit of a chicken-egg problem, since you usually get the SVN client from macports but you can also download svn from http://www.codingmonkeys.de/mbo.

Alternate instructions can be found on the [http://trac.macports.org/wiki/howto/SyncingWithSVN macports website]

If you don't have internet at all, or the above seems to be too complicated you can also create a binary package file on a computer that has MacPorts installed and then install it on the target computer. Please note that it is not recommended to install such a binary package on a computer that has MacPorts installed, since the binary installer does not (yet) talk to the MacPorts system to register the ports, so you might get ugly conflicts.

That being said, you can create a Mac OS X installer for EiffelStudio and all dependencies by typing
<pre>
sudo port mpkg eiffelstudio
</pre>

You can then find the .mpkg file in /opt/local/var/macports/build/<folder name that contains the word eiffelstudio>

The folder name might look something like this "_Volumes_Data_SVN_macports_dports_lang_eiffelstudio". Just copy the .mpkg file to the target computer. It can then be installed by simply double clicking it. Note however that the build and and the target machine should be of the same architecture (Intel or PPC) and of the same major OS release.

== FAQ ==
'''I get a crash with a Permission denied: Operating system error, how do I fix it?'''
Answer: Delete the .ec directory in your home directory.

'''I get a linking error with precompiles on PPC, why is that ?'''
Answer: Precompiles don't seem to work (well) with gcc on the Mac. This seems to be a limitation of the linker on both PPC and Intel. To work around this issue don't use precompiles on Macs.

==Hints==
* Use Helvetica 12 as Editor font. If you prefer a smaller font, use Hei 10.
* Pick and Drop works with Apple-key + mouse click.
* To set up the correct (default) browsers use "open" as your command-line browser in Tools>Preferences...
[[Image:preferences_open_mac.jpg]]
* To run the '''ec''' compiler from your shell, set up variables similar to these (e.g. in ~/.profile):
<pre>
# Setting variables for EiffelStudio.
export ISE_EIFFEL=/Applications/MacPorts/Eiffel61
export ISE_PLATFORM=macosx-ppc (or macosx-x86)
export ISE_PROJECTS=$HOME
export ES_PATH=$ISE_EIFFEL/studio/spec/$ISE_PLATFORM/bin
export PATH=$ES_PATH:$PATH
</pre>
* The F10 and F11 debugging shortcuts conflict with the standard Exposé keys. Here are some workarounds:
** Use the toolbar instead.
** Reassign these shortcuts in EiffelStudio (Tools>Preferences).
** Reassign the Exposé keys in System Preferences.
* The version of '''X11 installed with Mac OS X Leopard 10.5.0 and 10.5.1 does not work'''. The 10.5.2 and 10.5.3 updates are probably ok, however, but if you're having problems have a look at http://trac.macosforge.org/projects/xquartz. For more details, see http://www.eiffelroom.com/blog/paulbates/a_little_help_for_mac_users which pre-dates the release of 10.5.2.

EiffelOnMac

2009-04-01T08:47:25Z

Roederja: /* Working around firewall issues */

[[Category:EiffelStudio]]
[[Category:Macintosh]]

This page gives you an overview about how to get EiffelStudio running on your Mac.

== Installation using MacPorts ==

The officially supported versions of Mac OS X are 10.4 and 10.5.

MacPorts is a great tool that allows you to use many Unix applications on the Mac. We have created a package in the MacPorts repository that allows you to to install a fairly recent build with all dependencies in a convenient way. Install MacPorts as described [http://trac.macosforge.org/projects/macports/wiki/InstallingMacPorts here]. This might add the line 'export DISPLAY=:0.0' to your .profile (or .bashrc) file. This is valid for Tiger, but will prevent EiffelStudio launching in Leopard. Make sure this line is deleted if using Leopard. For more information consult the [http://guide.macports.org/ MacPorts guide] (which seems to be more up-to-date).

Now simply type:
<pre>
sudo port install eiffelstudio
</pre>
and you're ready to go (after a few hours compiling that is :)). Compiling on a new Intel Mac reportedly takes about an hour. An old 800 MHz PowerPC takes about seven hours.

The latest development build is available in the eiffelstudio-devel port. To install it type:
<pre>
sudo port install eiffelstudio-devel
</pre>
It can be installed alongside the regular ES build.

'''Note:''' Precompiles do not work well on the Mac. If you still want to give it a shot, you need to precompile the '''base''' and '''vision2''' libraries once with admin rights. To do that, you can type: "sudo estudio" in an xterm window and then use the precompilation wizard (Tools>Precompilation wizard) or simply create a new project that will be precompiled. On Mac OS 10.5 (Leopard) this doesn't seem to work anymore. Here you need to set the permissions of the precompile folder to world writeable (or at least writeable for your current user). To do this type chmod a+w $ISE_EIFFEL/precomp. You can change it back after completing the precompilation: chmod 755 $ISE_EIFFEL/precomp.

== Starting EiffelStudio ==

Simply navigate to /Applications/MacPorts/Eiffel<nn> and double click the EiffelStudio icon. This will automatically start X11.

Alternatively, you can also start EiffelStudio from X11 by simply entering the command 'estudio'. You can also 'sudo estudio', but the sudo does not seem to ever be needed even with a standard (non-admin) usercode (and you do use a standard usercode right? Admin usercodes are bad, can corrupt things, allow hackers (total count so far 0) more access. Also your users might not be running admin, so you should run standard and test under standard. Another tip – don't call your admin usercode 'admin'.)

== Disable Precompiles ==

For some reason (ask the Eiffel For Mac guys), precompiles for 6.2 don't work on the Mac. When you create a project, EiffelStudio will ask if you want to perform precompiles – say no. You must then disable the precompiles. Do this from the Project>Project Settings menu. Under the 'Groups>Precompile' section, remove all precompiles (eg., base_pre). Select the 'base_pre' precompile and click the red cross delete tool at the top of the window.

If you are not using EiffelStudio, you can delete the precompile lines in the projects .ecf file (eg., <precompile name="base_pre" location="$ISE_PRECOMP/base.ecf"/>)

{{Note|Precompiling the Eiffel libraries after installing the Port is possible, there are security policies to take into account. The Port installs EiffelStudio under the system's ''/Application/MacPorts'' directory and '''not''' the user ''~/Application/MacPorts''. Due of this, EiffelStudio must be run as a super user and the precompiles build using the '''Tools''' > '''Precompile Wizard''' option. Alternatively, alter the base installation path when requesting to install the Port.}}

== Upgrading ==

When a new version of EiffelStudio is available, you can upgrade like so:
<pre>
sudo port selfupdate
sudo port upgrade eiffelstudio
</pre>

Be prepared for another long wait while it compiles. You can do likewise for eiffelstudio-devel, of course.

Beware that this may not get the latest release if [http://trac.macports.org/browser/trunk/dports/lang/eiffelstudio/Portfile the Port file] has not been updated yet. Even after it has been updated, it may take a week for it to propagate to MacPorts. If you can't wait, here's how to get the latest version immediately:
# Edit your local copy of the Portfile: '''sudo port edit eiffelstudio'''. Change '''minor_version''' and '''version'''. Save.
# Tell MacPorts to use the local copy of your Portfile: '''cd /opt/local/var/macports/sources/rsync.macports.org/release/ports''' (assuming this is where your ports are), then type '''portindex'''. It will print hundreds of "Adding port" messages, one of which should be lang/eiffelstudio.
# Find out the checksums for the new version: '''sudo port -d upgrade eiffelstudio'''.
# Edit your local Portfile again, substituting the checksums.
# Now '''sudo port upgrade eiffelstudio''' should upgrade to the version described in your local Portfile.

== Working around firewall issues ==
If you can't use the MacPorts rsync repository due to your firewall you can check out the macports source tree via SVN. To do this open a Terminal window and cd to a directory where you want your ports tree to live. Then type:
<pre>
svn co http://svn.macports.org/repository/macports/trunk/dports/
</pre>
After the command has finished open the file /opt/local/etc/macports/sources.conf in your favorite text editor. Comment out the rsync URL and add a file URL that points to the dports directory that you just checked out from the SVN repository. Your sources.conf file will then look something like that:
<pre>
# To get macports from the macports rsync server use:
# rsync://rsync.macports.org/release/ports/

file:///Volumes/Data/SVN/macports/dports
</pre>

Note: The above steps only work when you have an SVN client installed. This is a bit of a chicken-egg problem, since you usually get the SVN client from macports but you can also download svn from http://www.codingmonkeys.de/mbo.

Alternate instructions can be found on the [http://trac.macports.org/wiki/howto/SyncingWithSVN macports website]

If you don't have internet at all, or the above seems to be too complicated you can also create a binary package file on a computer that has MacPorts installed and then install it on the target computer. Please note that it is not recommended to install such a binary package on a computer that has MacPorts installed, since the binary installer does not (yet) talk to the MacPorts system to register the ports, so you might get ugly conflicts.

That being said, you can create a Mac OS X installer for EiffelStudio and all dependencies by typing
<pre>
sudo port mpkg eiffelstudio
</pre>

You can then find the .mpkg file in /opt/local/var/macports/build/<folder name that contains the word eiffelstudio>

The folder name might look something like this "_Volumes_Data_SVN_macports_dports_lang_eiffelstudio". Just copy the .mpkg file to the target computer. It can then be installed by simply double clicking it. Note however that the build and and the target machine should be of the same architecture (Intel or PPC) and of the same major OS release.

== FAQ ==
'''I get a crash with a Permission denied: Operating system error, how do I fix it?'''
Answer: Delete the .ec directory in your home directory.

'''I get a linking error with precompiles on PPC, why is that ?'''
Answer: Precompiles don't seem to work (well) with gcc on the Mac. This seems to be a limitation of the linker on both PPC and Intel. To work around this issue don't use precompiles on Macs.

==Hints==
* Use Helvetica 12 as Editor font. If you prefer a smaller font, use Hei 10.
* Pick and Drop works with Apple-key + mouse click.
* To set up the correct (default) browsers use "open" as your command-line browser in Tools>Preferences...
[[Image:preferences_open_mac.jpg]]
* To run the '''ec''' compiler from your shell, set up variables similar to these (e.g. in ~/.profile):
<pre>
# Setting variables for EiffelStudio.
export ISE_EIFFEL=/Applications/MacPorts/Eiffel61
export ISE_PLATFORM=macosx-ppc (or macosx-x86)
export ISE_PROJECTS=$HOME
export ES_PATH=$ISE_EIFFEL/studio/spec/$ISE_PLATFORM/bin
export PATH=$ES_PATH:$PATH
</pre>
* The F10 and F11 debugging shortcuts conflict with the standard Exposé keys. Here are some workarounds:
** Use the toolbar instead.
** Reassign these shortcuts in EiffelStudio (Tools>Preferences).
** Reassign the Exposé keys in System Preferences.
* The version of '''X11 installed with Mac OS X Leopard 10.5.0 and 10.5.1 does not work'''. The 10.5.2 and 10.5.3 updates are probably ok, however, but if you're having problems have a look at http://trac.macosforge.org/projects/xquartz. For more details, see http://www.eiffelroom.com/blog/paulbates/a_little_help_for_mac_users which pre-dates the release of 10.5.2.

Testing Tool (Specification)

2009-03-22T15:14:19Z

Roederja: /* Compatibility with Getest = */

[[Category:Testing]]

{{UnderConstruction}}

== Main functionalities ==

=== Add unit/system level tests ===

Semantically there is no difference between unit tests and system level tests. This way all tests can be written in Eiffel in a conforming way.

A test is a arbitrary routine in a class inheriting from '''EQA_TEST_SET''' (the routine must be exported to '''ANY''').

==== System level test specifics (not yet implemented) ====

Since system level testing often relies on external items like files, '''SYSTEM_LEVEL_EQA_TEST_SET''' provides a number of helper routines accessing them. These classes will probably have to be in an special testing library, since they also make use of other libraries such as the process library.

==== Location of tests (config file) ====

Tests can be located in any cluster of the system. In addition one can define test specific clusters through in the .ecf file. These clusters do not need to exists for the project to compile. This allows one to have library tests but being able to deliver the library without including the test suite.
For all classes in the test clusters, the inheritance structure will be evaluated so test classes inheriting from EQA_TEST_SET can be found. For any class belonging to a normal cluster, it will have to be reachable from root class to be compiled and detected as a test class. This means the recommended practice is to put test classes into a test cluster, but it is not a rule.

{{Note| Not all classes in a test cluster have to be classes containing tests. One example are helper classes.}}

Test clusters are also needed to provide a location for test generation/extraction.

==== Additional information ====

The indexing clause can be used to specify which classes and routines are tested by the test routine. Any specifications in the class indexing clause will apply to all tests in that class. Note the '''covers/''' tag in the following examples.

==== Examples ====

Example unit tests '''test_append''' and '''test_boolean'''
<eiffel>

frozen class STRING_TESTS

inherit

EQA_TEST_SET
redefine
set_up
end

feature {NONE} -- Initialization

set_up
do
create s.make (10)
end

feature {TESTER} -- Access

s: STRING

feature {TESTER} -- Test routines

test_append
indexing
testing: "covers/{STRING}.append, platform/os/winxp"
require
set_up: s /= Void and then s.is_empty
do
s.append ("12345")
assert ("append", s.is_equal ("12345")
end

test_boolean
indexing
testing: "covers/{STRING}.is_boolean, covers/{STRING}.to_boolean"
require
set_up: s /= Void and then s.is_empty
do
s.append ("True")
assert ("boolean", s.is_boolean and then s.to_boolean)
end

end

</eiffel>

Example system level test '''test_version''' (Note: '''EQA_SYSTEM_LEVEL_TEST_SET''' inherits from '''EQA_TEST_SET''' and provides basic functionality for executing external commands, including the system currently under development):

<eiffel>

indexing
testing_covers: "all"

frozen class TEST_MY_APP

inherit

EQA_SYSTEM_LEVEL_TEST_SET

feature {TESTER} -- Test routines

test_version
indexing
testing: "platform/os/linux/x86"
do
run_system_with_args ("--version")
assert_string_equality ("version", last_output, "my_app version 0.1 - linux x86")
end

end

</eiffel>

=== Manage and run test suite ===

[[Image:testing_set-view.png|right|400px|thumb|Standard view listing existing test sets and the tests they contain]]
[[Image:testing_cut-view.png|right|400px|thumb|Predefined ''Class tested'' view listing classes/features of the system together with the associated tests (Note: since test_boolean is tagged to cover multiple features, it also appears multiple times in the view)]]
[[Image:testing_user-view.png|right|400px|thumb|User defined view (by simply typing part of the tag), where the tool creates a view based on how the tests are tagged (see Examples above)]]

The tool should have an own icon for displaying test cases (test routines). In this example it is a Lego block. Especially for views like ''list all tests for this routine'', it is important to see the difference between the actual routine and its tests. Also the tool has more of a vertical layout. Since the number of tests is comparable to the number of classes in the system, it makes sense the tools have the same layout. Also it allows to have tabs in the bottom for displaying further information, such as execution details (output, call stack, etc.).

The '''menu bar''' includes following buttons:
* Create new manual test case (opens wizard)
** if test class is dropped on button, the wizard will suggest to create new test in that class
** if normal class (or feature) is dropped on button, wizard will suggest to create test for the class (or feature)
* Menu for generating new test (defaults to last chosen one?)
** if normal class/feature is dropped on button, generate tests for that class/feature

* Menu for executing tests in background (defaults to last chosen one?)
** if any class/feature is dropped on button, run tests associated with class/feature
* Run test in debugger (must have a test selected or dropped on button to start)
* Stop any execution (background or debugger)

* Opens settings dialog for testing

* Status indicating how many tests we have ran so far and
* how many failing ones there are

'''View''' defines in which way the test cases are listed (see below).

'''Filter''' can be used to type keywords for showing only test cases having tags including the keywords (see below). It's a drop down so predefined filter patterns can be used (such as ''outcome.fail'').

The '''grid''' contains a tree view of all test cases (test cases are always in leaves). Multiples columns for more information. Currently there are two indications whether a test fails or not (column and icons). Obviously it only needs one - they are both shown just to see the difference. The advantage with using icons is that less space is needed. Coloring the background of a row containing a failing test case would be an option as well.

==== Tags ====

Each test can have a number of tags. Tags can be a single string or hierarchically structured with slashes ('/'). For example, a test with tag ''covers/{STRING}.append'' means that this test is a regression test for {STRING}.append. There are a number of implicit tags for each test, such like the ''class'' tag ({STRING_TESTS}.test_append has the implicit tag ''class/{STRING_TESTS}.test_append'').

{{Note|Tags are defined as strings, but in the view we sometimes want a tag to represent a class, or a feature. The way this is done right now is that the view basically knows if the tag starts with "covers/" it is followed by a class and feature name. Another approach would be to define such tags like this: "covers.{CLASS_NAME}.feature_name". This would allow user defined tags to have clickable nodes in the view. We could also introduces other special tags such like dates/times.}}

==== Different views ====

Based on the notion of tags, we are able to define different views. The default view ''Test sets'' simply shows a hierarchical tree for every ''name.X'' tag. This enables us to define more views, such as ''Class tested'', which displays every ''covers.X'' tag. Note that with other tags than ''name.'' some tests might get listed multiple times where other not containing such a tag must be listed explicitly. The main advantage is that the user can define his own views based on any type of tags.

{{Note|The tools should support multiple selection. This is important for executing a number of selected test routines, showing passed execution results, etc. Also when selecting a e.g. class node it should execute all leaves below that node.}}

==== Running tests ====
[[Image:testing_run-menu.jpg]]

The '''run''' menu provides different options for running tests in the background:

* Run all tests in system
* Run currently failing ones
* Run test for classes last modified (better description needed here)
* Only run tests shown below
* Only run tests which are selected below

{{Note|We should have two different views for displaying testing history. One structured by test sessions (list of test execution containing all test routines for each session) and one listing recent executions for a single test routine.}}

=== Generate tests automatically ===

[[Image:testing_generate-menu.jpg]]

The '''generate''' menu lets you generate new tests for all classes in system (randomly picked?) or for classes which where last modified.

=== Extract tests from a running application ===

This is the a simple example of an extracted test case (note that '''EQA_EXTRACTED_TEST_SET''' inherits from '''EQA_TEST_SET''' and implements all functionality for executing an extracted test).

<eiffel>
indexing
testing: "type/extracted"

class
STRING_TESTS_001

inherit

EQA_EXTRACTED_TEST_SET

feature {TESTER} -- Test routines

test_append_integer
-- Call `routine_under_test' with input provided by `context'.
indexing
tag: "covers/{STRING}.append_integer"
do
run_extracted_test (agent {STRING}.append_integer, ["#1", 100])
end

feature {NONE} -- Access

context: !ARRAY [!TUPLE [type: !TYPE [ANY]; attributes: !TUPLE; inv: BOOLEAN]]
-- <Precursor>
once
Result := <<
[{STRING}, [
"this is an integer: "
], False]
>>
end

end -- class STRING_TESTS_001

</eiffel>

Each test routines passes the agent of the routine to be tested, along with a tuple containing the arguments (#x refering to objects in `context'). This basically replaces the missing reflection functionality for calling features. '''context''' is also deferred in '''EQA_EXTACTED_TEST_SET''' and contains all data from the heap and call stack which was reachable by the routine at extraction time. Each TUPLE represents an object, where `inv' defines whether the object should fulfill its invariant or not (if the object was on the stack at extraction time, this does not have to be the case).

This design lets us have the entire test in one file. This is practical especially in the situation where a user should submit such a test as a bug report after experiencing a crash.
The reason for that is mainly the set_up procedure. Creating all objects in '''context''' must be done during set_up. If there is a failure, the set_up will be blamed instead of the actual test routine, which makes the test not fail but invalid. This can happen e.g. if one of the objects in the context does not fulfill its invariant, which again could result from simply editing the class being tested. Any suggestions welcome!

=== Background test execution ===
== Open questions ==
(This section should disappear as the questions get answered.)

== Wish list ==

If you have any suggestions or ideas which would improve the testing tool, please add them to this section.

=== tests with context ===
it would be nice to have contextual test cases.
For instance you would create a test class
and you create an associated "test point" (kind of breakpoint, or like aspect programming)
and then, when you run the execution in "testing mode" (under the debugger, or testing tool)
whenever you reach this "test point", it would trigger the associated test case.
I agree, it is not anymore automatic testing, since you need to make sure the execution goes by this "test point",
but this would be useful to launch specific test with a valid context.

=== jUnit compatible output format ===
It would be nice if the testing tool could generate a jUnit compatible output which can then be processed by other tools like a continuous build system. Of course this makes it necessary for the testing tool to be available from the command line.

=== Compatibility with Getest ===
Since Gobo test has been available long before Eiffel test, it would be nice if the testing tool also supported GOBO test cases. This is probably really easy to do since the difference are minimal. Basically only that gobo test cases require a creation procedure. It would also be a good start if EiffelTest would still recognize test cases when they list a creation procedure(s) as long as default_create is listed.

== See also ==

* [[Testing Tool (Architecture)]]
* [[Eweasel]]
* [[CddBranch]]
* [[Eiffel Testing Tool]]

Testing Tool (Specification)

2009-03-22T15:14:05Z

Roederja: /* Wish list */

[[Category:Testing]]

{{UnderConstruction}}

== Main functionalities ==

=== Add unit/system level tests ===

Semantically there is no difference between unit tests and system level tests. This way all tests can be written in Eiffel in a conforming way.

A test is a arbitrary routine in a class inheriting from '''EQA_TEST_SET''' (the routine must be exported to '''ANY''').

==== System level test specifics (not yet implemented) ====

Since system level testing often relies on external items like files, '''SYSTEM_LEVEL_EQA_TEST_SET''' provides a number of helper routines accessing them. These classes will probably have to be in an special testing library, since they also make use of other libraries such as the process library.

==== Location of tests (config file) ====

Tests can be located in any cluster of the system. In addition one can define test specific clusters through in the .ecf file. These clusters do not need to exists for the project to compile. This allows one to have library tests but being able to deliver the library without including the test suite.
For all classes in the test clusters, the inheritance structure will be evaluated so test classes inheriting from EQA_TEST_SET can be found. For any class belonging to a normal cluster, it will have to be reachable from root class to be compiled and detected as a test class. This means the recommended practice is to put test classes into a test cluster, but it is not a rule.

{{Note| Not all classes in a test cluster have to be classes containing tests. One example are helper classes.}}

Test clusters are also needed to provide a location for test generation/extraction.

==== Additional information ====

The indexing clause can be used to specify which classes and routines are tested by the test routine. Any specifications in the class indexing clause will apply to all tests in that class. Note the '''covers/''' tag in the following examples.

==== Examples ====

Example unit tests '''test_append''' and '''test_boolean'''
<eiffel>

frozen class STRING_TESTS

inherit

EQA_TEST_SET
redefine
set_up
end

feature {NONE} -- Initialization

set_up
do
create s.make (10)
end

feature {TESTER} -- Access

s: STRING

feature {TESTER} -- Test routines

test_append
indexing
testing: "covers/{STRING}.append, platform/os/winxp"
require
set_up: s /= Void and then s.is_empty
do
s.append ("12345")
assert ("append", s.is_equal ("12345")
end

test_boolean
indexing
testing: "covers/{STRING}.is_boolean, covers/{STRING}.to_boolean"
require
set_up: s /= Void and then s.is_empty
do
s.append ("True")
assert ("boolean", s.is_boolean and then s.to_boolean)
end

end

</eiffel>

Example system level test '''test_version''' (Note: '''EQA_SYSTEM_LEVEL_TEST_SET''' inherits from '''EQA_TEST_SET''' and provides basic functionality for executing external commands, including the system currently under development):

<eiffel>

indexing
testing_covers: "all"

frozen class TEST_MY_APP

inherit

EQA_SYSTEM_LEVEL_TEST_SET

feature {TESTER} -- Test routines

test_version
indexing
testing: "platform/os/linux/x86"
do
run_system_with_args ("--version")
assert_string_equality ("version", last_output, "my_app version 0.1 - linux x86")
end

end

</eiffel>

=== Manage and run test suite ===

[[Image:testing_set-view.png|right|400px|thumb|Standard view listing existing test sets and the tests they contain]]
[[Image:testing_cut-view.png|right|400px|thumb|Predefined ''Class tested'' view listing classes/features of the system together with the associated tests (Note: since test_boolean is tagged to cover multiple features, it also appears multiple times in the view)]]
[[Image:testing_user-view.png|right|400px|thumb|User defined view (by simply typing part of the tag), where the tool creates a view based on how the tests are tagged (see Examples above)]]

The tool should have an own icon for displaying test cases (test routines). In this example it is a Lego block. Especially for views like ''list all tests for this routine'', it is important to see the difference between the actual routine and its tests. Also the tool has more of a vertical layout. Since the number of tests is comparable to the number of classes in the system, it makes sense the tools have the same layout. Also it allows to have tabs in the bottom for displaying further information, such as execution details (output, call stack, etc.).

The '''menu bar''' includes following buttons:
* Create new manual test case (opens wizard)
** if test class is dropped on button, the wizard will suggest to create new test in that class
** if normal class (or feature) is dropped on button, wizard will suggest to create test for the class (or feature)
* Menu for generating new test (defaults to last chosen one?)
** if normal class/feature is dropped on button, generate tests for that class/feature

* Menu for executing tests in background (defaults to last chosen one?)
** if any class/feature is dropped on button, run tests associated with class/feature
* Run test in debugger (must have a test selected or dropped on button to start)
* Stop any execution (background or debugger)

* Opens settings dialog for testing

* Status indicating how many tests we have ran so far and
* how many failing ones there are

'''View''' defines in which way the test cases are listed (see below).

'''Filter''' can be used to type keywords for showing only test cases having tags including the keywords (see below). It's a drop down so predefined filter patterns can be used (such as ''outcome.fail'').

The '''grid''' contains a tree view of all test cases (test cases are always in leaves). Multiples columns for more information. Currently there are two indications whether a test fails or not (column and icons). Obviously it only needs one - they are both shown just to see the difference. The advantage with using icons is that less space is needed. Coloring the background of a row containing a failing test case would be an option as well.

==== Tags ====

Each test can have a number of tags. Tags can be a single string or hierarchically structured with slashes ('/'). For example, a test with tag ''covers/{STRING}.append'' means that this test is a regression test for {STRING}.append. There are a number of implicit tags for each test, such like the ''class'' tag ({STRING_TESTS}.test_append has the implicit tag ''class/{STRING_TESTS}.test_append'').

{{Note|Tags are defined as strings, but in the view we sometimes want a tag to represent a class, or a feature. The way this is done right now is that the view basically knows if the tag starts with "covers/" it is followed by a class and feature name. Another approach would be to define such tags like this: "covers.{CLASS_NAME}.feature_name". This would allow user defined tags to have clickable nodes in the view. We could also introduces other special tags such like dates/times.}}

==== Different views ====

Based on the notion of tags, we are able to define different views. The default view ''Test sets'' simply shows a hierarchical tree for every ''name.X'' tag. This enables us to define more views, such as ''Class tested'', which displays every ''covers.X'' tag. Note that with other tags than ''name.'' some tests might get listed multiple times where other not containing such a tag must be listed explicitly. The main advantage is that the user can define his own views based on any type of tags.

{{Note|The tools should support multiple selection. This is important for executing a number of selected test routines, showing passed execution results, etc. Also when selecting a e.g. class node it should execute all leaves below that node.}}

==== Running tests ====
[[Image:testing_run-menu.jpg]]

The '''run''' menu provides different options for running tests in the background:

* Run all tests in system
* Run currently failing ones
* Run test for classes last modified (better description needed here)
* Only run tests shown below
* Only run tests which are selected below

{{Note|We should have two different views for displaying testing history. One structured by test sessions (list of test execution containing all test routines for each session) and one listing recent executions for a single test routine.}}

=== Generate tests automatically ===

[[Image:testing_generate-menu.jpg]]

The '''generate''' menu lets you generate new tests for all classes in system (randomly picked?) or for classes which where last modified.

=== Extract tests from a running application ===

This is the a simple example of an extracted test case (note that '''EQA_EXTRACTED_TEST_SET''' inherits from '''EQA_TEST_SET''' and implements all functionality for executing an extracted test).

<eiffel>
indexing
testing: "type/extracted"

class
STRING_TESTS_001

inherit

EQA_EXTRACTED_TEST_SET

feature {TESTER} -- Test routines

test_append_integer
-- Call `routine_under_test' with input provided by `context'.
indexing
tag: "covers/{STRING}.append_integer"
do
run_extracted_test (agent {STRING}.append_integer, ["#1", 100])
end

feature {NONE} -- Access

context: !ARRAY [!TUPLE [type: !TYPE [ANY]; attributes: !TUPLE; inv: BOOLEAN]]
-- <Precursor>
once
Result := <<
[{STRING}, [
"this is an integer: "
], False]
>>
end

end -- class STRING_TESTS_001

</eiffel>

Each test routines passes the agent of the routine to be tested, along with a tuple containing the arguments (#x refering to objects in `context'). This basically replaces the missing reflection functionality for calling features. '''context''' is also deferred in '''EQA_EXTACTED_TEST_SET''' and contains all data from the heap and call stack which was reachable by the routine at extraction time. Each TUPLE represents an object, where `inv' defines whether the object should fulfill its invariant or not (if the object was on the stack at extraction time, this does not have to be the case).

This design lets us have the entire test in one file. This is practical especially in the situation where a user should submit such a test as a bug report after experiencing a crash.
The reason for that is mainly the set_up procedure. Creating all objects in '''context''' must be done during set_up. If there is a failure, the set_up will be blamed instead of the actual test routine, which makes the test not fail but invalid. This can happen e.g. if one of the objects in the context does not fulfill its invariant, which again could result from simply editing the class being tested. Any suggestions welcome!

=== Background test execution ===
== Open questions ==
(This section should disappear as the questions get answered.)

== Wish list ==

If you have any suggestions or ideas which would improve the testing tool, please add them to this section.

=== tests with context ===
it would be nice to have contextual test cases.
For instance you would create a test class
and you create an associated "test point" (kind of breakpoint, or like aspect programming)
and then, when you run the execution in "testing mode" (under the debugger, or testing tool)
whenever you reach this "test point", it would trigger the associated test case.
I agree, it is not anymore automatic testing, since you need to make sure the execution goes by this "test point",
but this would be useful to launch specific test with a valid context.

=== jUnit compatible output format ===
It would be nice if the testing tool could generate a jUnit compatible output which can then be processed by other tools like a continuous build system. Of course this makes it necessary for the testing tool to be available from the command line.

== Compatibility with Getest ===
Since Gobo test has been available long before Eiffel test, it would be nice if the testing tool also supported GOBO test cases. This is probably really easy to do since the difference are minimal. Basically only that gobo test cases require a creation procedure. It would also be a good start if EiffelTest would still recognize test cases when they list a creation procedure(s) as long as default_create is listed.

== See also ==

* [[Testing Tool (Architecture)]]
* [[Eweasel]]
* [[CddBranch]]
* [[Eiffel Testing Tool]]

Testing Tool (Specification)

2009-03-20T17:18:20Z

Roederja: /* tests with context */

[[Category:Testing]]

{{UnderConstruction}}

== Main functionalities ==

=== Add unit/system level tests ===

Semantically there is no difference between unit tests and system level tests. This way all tests can be written in Eiffel in a conforming way.

A test is a arbitrary routine in a class inheriting from '''EQA_TEST_SET''' (the routine must be exported to '''ANY''').

==== System level test specifics (not yet implemented) ====

Since system level testing often relies on external items like files, '''SYSTEM_LEVEL_EQA_TEST_SET''' provides a number of helper routines accessing them. These classes will probably have to be in an special testing library, since they also make use of other libraries such as the process library.

==== Location of tests (config file) ====

Tests can be located in any cluster of the system. In addition one can define test specific clusters through in the .ecf file. These clusters do not need to exists for the project to compile. This allows one to have library tests but being able to deliver the library without including the test suite.
For all classes in the test clusters, the inheritance structure will be evaluated so test classes inheriting from EQA_TEST_SET can be found. For any class belonging to a normal cluster, it will have to be reachable from root class to be compiled and detected as a test class. This means the recommended practice is to put test classes into a test cluster, but it is not a rule.

{{Note| Not all classes in a test cluster have to be classes containing tests. One example are helper classes.}}

Test clusters are also needed to provide a location for test generation/extraction.

==== Additional information ====

The indexing clause can be used to specify which classes and routines are tested by the test routine. Any specifications in the class indexing clause will apply to all tests in that class. Note the '''covers/''' tag in the following examples.

==== Examples ====

Example unit tests '''test_append''' and '''test_boolean'''
<eiffel>

frozen class STRING_TESTS

inherit

EQA_TEST_SET
redefine
set_up
end

feature {NONE} -- Initialization

set_up
do
create s.make (10)
end

feature {TESTER} -- Access

s: STRING

feature {TESTER} -- Test routines

test_append
indexing
testing: "covers/{STRING}.append, platform/os/winxp"
require
set_up: s /= Void and then s.is_empty
do
s.append ("12345")
assert ("append", s.is_equal ("12345")
end

test_boolean
indexing
testing: "covers/{STRING}.is_boolean, covers/{STRING}.to_boolean"
require
set_up: s /= Void and then s.is_empty
do
s.append ("True")
assert ("boolean", s.is_boolean and then s.to_boolean)
end

end

</eiffel>

Example system level test '''test_version''' (Note: '''EQA_SYSTEM_LEVEL_TEST_SET''' inherits from '''EQA_TEST_SET''' and provides basic functionality for executing external commands, including the system currently under development):

<eiffel>

indexing
testing_covers: "all"

frozen class TEST_MY_APP

inherit

EQA_SYSTEM_LEVEL_TEST_SET

feature {TESTER} -- Test routines

test_version
indexing
testing: "platform/os/linux/x86"
do
run_system_with_args ("--version")
assert_string_equality ("version", last_output, "my_app version 0.1 - linux x86")
end

end

</eiffel>

=== Manage and run test suite ===

[[Image:testing_set-view.png|right|400px|thumb|Standard view listing existing test sets and the tests they contain]]
[[Image:testing_cut-view.png|right|400px|thumb|Predefined ''Class tested'' view listing classes/features of the system together with the associated tests (Note: since test_boolean is tagged to cover multiple features, it also appears multiple times in the view)]]
[[Image:testing_user-view.png|right|400px|thumb|User defined view (by simply typing part of the tag), where the tool creates a view based on how the tests are tagged (see Examples above)]]

The tool should have an own icon for displaying test cases (test routines). In this example it is a Lego block. Especially for views like ''list all tests for this routine'', it is important to see the difference between the actual routine and its tests. Also the tool has more of a vertical layout. Since the number of tests is comparable to the number of classes in the system, it makes sense the tools have the same layout. Also it allows to have tabs in the bottom for displaying further information, such as execution details (output, call stack, etc.).

The '''menu bar''' includes following buttons:
* Create new manual test case (opens wizard)
** if test class is dropped on button, the wizard will suggest to create new test in that class
** if normal class (or feature) is dropped on button, wizard will suggest to create test for the class (or feature)
* Menu for generating new test (defaults to last chosen one?)
** if normal class/feature is dropped on button, generate tests for that class/feature

* Menu for executing tests in background (defaults to last chosen one?)
** if any class/feature is dropped on button, run tests associated with class/feature
* Run test in debugger (must have a test selected or dropped on button to start)
* Stop any execution (background or debugger)

* Opens settings dialog for testing

* Status indicating how many tests we have ran so far and
* how many failing ones there are

'''View''' defines in which way the test cases are listed (see below).

'''Filter''' can be used to type keywords for showing only test cases having tags including the keywords (see below). It's a drop down so predefined filter patterns can be used (such as ''outcome.fail'').

The '''grid''' contains a tree view of all test cases (test cases are always in leaves). Multiples columns for more information. Currently there are two indications whether a test fails or not (column and icons). Obviously it only needs one - they are both shown just to see the difference. The advantage with using icons is that less space is needed. Coloring the background of a row containing a failing test case would be an option as well.

==== Tags ====

Each test can have a number of tags. Tags can be a single string or hierarchically structured with slashes ('/'). For example, a test with tag ''covers/{STRING}.append'' means that this test is a regression test for {STRING}.append. There are a number of implicit tags for each test, such like the ''class'' tag ({STRING_TESTS}.test_append has the implicit tag ''class/{STRING_TESTS}.test_append'').

{{Note|Tags are defined as strings, but in the view we sometimes want a tag to represent a class, or a feature. The way this is done right now is that the view basically knows if the tag starts with "covers/" it is followed by a class and feature name. Another approach would be to define such tags like this: "covers.{CLASS_NAME}.feature_name". This would allow user defined tags to have clickable nodes in the view. We could also introduces other special tags such like dates/times.}}

==== Different views ====

Based on the notion of tags, we are able to define different views. The default view ''Test sets'' simply shows a hierarchical tree for every ''name.X'' tag. This enables us to define more views, such as ''Class tested'', which displays every ''covers.X'' tag. Note that with other tags than ''name.'' some tests might get listed multiple times where other not containing such a tag must be listed explicitly. The main advantage is that the user can define his own views based on any type of tags.

{{Note|The tools should support multiple selection. This is important for executing a number of selected test routines, showing passed execution results, etc. Also when selecting a e.g. class node it should execute all leaves below that node.}}

==== Running tests ====
[[Image:testing_run-menu.jpg]]

The '''run''' menu provides different options for running tests in the background:

* Run all tests in system
* Run currently failing ones
* Run test for classes last modified (better description needed here)
* Only run tests shown below
* Only run tests which are selected below

{{Note|We should have two different views for displaying testing history. One structured by test sessions (list of test execution containing all test routines for each session) and one listing recent executions for a single test routine.}}

=== Generate tests automatically ===

[[Image:testing_generate-menu.jpg]]

The '''generate''' menu lets you generate new tests for all classes in system (randomly picked?) or for classes which where last modified.

=== Extract tests from a running application ===

This is the a simple example of an extracted test case (note that '''EQA_EXTRACTED_TEST_SET''' inherits from '''EQA_TEST_SET''' and implements all functionality for executing an extracted test).

<eiffel>
indexing
testing: "type/extracted"

class
STRING_TESTS_001

inherit

EQA_EXTRACTED_TEST_SET

feature {TESTER} -- Test routines

test_append_integer
-- Call `routine_under_test' with input provided by `context'.
indexing
tag: "covers/{STRING}.append_integer"
do
run_extracted_test (agent {STRING}.append_integer, ["#1", 100])
end

feature {NONE} -- Access

context: !ARRAY [!TUPLE [type: !TYPE [ANY]; attributes: !TUPLE; inv: BOOLEAN]]
-- <Precursor>
once
Result := <<
[{STRING}, [
"this is an integer: "
], False]
>>
end

end -- class STRING_TESTS_001

</eiffel>

Each test routines passes the agent of the routine to be tested, along with a tuple containing the arguments (#x refering to objects in `context'). This basically replaces the missing reflection functionality for calling features. '''context''' is also deferred in '''EQA_EXTACTED_TEST_SET''' and contains all data from the heap and call stack which was reachable by the routine at extraction time. Each TUPLE represents an object, where `inv' defines whether the object should fulfill its invariant or not (if the object was on the stack at extraction time, this does not have to be the case).

This design lets us have the entire test in one file. This is practical especially in the situation where a user should submit such a test as a bug report after experiencing a crash.
The reason for that is mainly the set_up procedure. Creating all objects in '''context''' must be done during set_up. If there is a failure, the set_up will be blamed instead of the actual test routine, which makes the test not fail but invalid. This can happen e.g. if one of the objects in the context does not fulfill its invariant, which again could result from simply editing the class being tested. Any suggestions welcome!

=== Background test execution ===
== Open questions ==
(This section should disappear as the questions get answered.)

== Wish list ==

If you have any suggestions or ideas which would improve the testing tool, please add them to this section.

=== tests with context ===
it would be nice to have contextual test cases.
For instance you would create a test class
and you create an associated "test point" (kind of breakpoint, or like aspect programming)
and then, when you run the execution in "testing mode" (under the debugger, or testing tool)
whenever you reach this "test point", it would trigger the associated test case.
I agree, it is not anymore automatic testing, since you need to make sure the execution goes by this "test point",
but this would be useful to launch specific test with a valid context.

=== jUnit compatible output format ===
It would be nice if the testing tool could generate a jUnit compatible output which can then be processed by other tools like a continuous build system. Of course this makes it necessary for the testing tool to be available from the command line.

== See also ==

* [[Testing Tool (Architecture)]]
* [[Eweasel]]
* [[CddBranch]]
* [[Eiffel Testing Tool]]

Downloads

2008-10-24T10:17:59Z

Roederja: /* EiffelStudio 6.x Pre-releases */

[[Category:EiffelStudio]]
[[Category:Compiler]]
==EiffelStudio 6.x Pre-releases==
We provide versions of EiffelStudio for most popular platforms (Linux, Windows, Solaris, Irix, ...).

You can find the latest builds:
* in [http://eiffelstudio.origo.ethz.ch/download the Origo download area]
* from the download page of [http://sourceforge.net/project/showfiles.php?group_id=196408 the sourceforge area]
* as well as in [ftp://beta:beta57@ftp.eiffel.com the Eiffel Software beta area].

Details about new features and bug fixes in the builds are on the [[EiffelStudio_Releases| releases page]].

{{Note|Please be aware that the 6.x versions released through this site are intermediate builds on the road towards official EiffelStudio 6.x. If you are experiencing problems with this release, please use the [http://eiffelstudio.origo.ethz.ch/forum EiffelStudio developer forums] for discussions.}}

The convention used for filenames is the following:
Eiffel61_gpl_$BUILD-$ISE_PLATFORM.[tar.bz2|msi]
Where '''$BUILD''' is a build number, the higher number the more recent release it is, and where '''$ISE_PLATFORM''' is the name of your platform.

Mac OS X builds can be found [[EiffelOnMac|here]].

On Windows, you can use [[Installing_Microsoft_C_compiler|the latest Microsoft C compiler]], but EiffelStudio 6.1 needs [[Installing_Microsoft_C_compiler_6.1_and_older|an older compiler]].

==EiffelStudio 6.x==
You can download the official EiffelStudio 6.x release from [http://www.eiffel.com/downloads/eiffelstudio.html Eiffel Software]. The GPL release can also be downloaded from [http://sourceforge.net/project/showfiles.php?group_id=196408 http://sflogo.sourceforge.net/sflogo.php?group_id=196408.png].

==Doc Builder==
You can download the documentation generation tool for Windows 32-bit with .NET 1.1 installed by extracting the content of [http://download.origo.ethz.ch/eiffelstudio/174/doc_builder.zip doc_builder.zip] (or [http://download.origo.ethz.ch/eiffelstudio/174/doc_builder_64-bit.zip doc_builder_64-bit.zip] for the 64-bit version) onto your hard-drive. Once installed, you can launch the tool by launching the '''doc_builder.exe''' executable.

If you have both .NET 1.1 and .NET 2.0 (or greater), you need to force the loading of .NET 1.1. To do so, edit the file '''doc_builder.exe.config''' so that its content looks like:

<xml>
<configuration>
<startup>
<requiredRuntime version="v1.1.4322" safemode="true"/>
</startup>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<probing privatePath="Assemblies"/>
</assemblyBinding>
</runtime>
</configuration>
</xml>