summaryrefslogtreecommitdiffstats log msg author committer range
diff options
 context: 12345678910152025303540 space: includeignore mode: unifiedssdiffstat only
Diffstat (limited to 'org.eclipse.jubula.documentation')
-rw-r--r--org.eclipse.jubula.documentation/manual/en/tex/BestPractices/Eventhandlers/global.tex13
-rw-r--r--org.eclipse.jubula.documentation/manual/en/tex/BestPractices/Eventhandlers/local.tex11
-rw-r--r--org.eclipse.jubula.documentation/manual/en/tex/BestPractices/Keywords/data.tex2
-rw-r--r--org.eclipse.jubula.documentation/manual/en/tex/BestPractices/Keywords/keywords.tex7
-rw-r--r--org.eclipse.jubula.documentation/manual/en/tex/BestPractices/Keywords/suites.tex23
-rw-r--r--org.eclipse.jubula.documentation/manual/en/tex/BestPractices/Naming/CONTENT.tex2
-rw-r--r--org.eclipse.jubula.documentation/manual/en/tex/BestPractices/Naming/cases.tex2
-rw-r--r--org.eclipse.jubula.documentation/manual/en/tex/BestPractices/Naming/comps.tex6
-rw-r--r--org.eclipse.jubula.documentation/manual/en/tex/BestPractices/Naming/suites.tex3
-rw-r--r--org.eclipse.jubula.documentation/manual/en/tex/BestPractices/Structure/tcb.tex2
-rw-r--r--org.eclipse.jubula.documentation/manual/en/tex/Concepts/Architecture/CONTENT.tex6
-rw-r--r--org.eclipse.jubula.documentation/manual/en/tex/Concepts/Architecture/client.tex5
-rw-r--r--org.eclipse.jubula.documentation/manual/en/tex/Concepts/Architecture/diffmachines.tex4
-rw-r--r--org.eclipse.jubula.documentation/manual/en/tex/Concepts/Architecture/overview.tex8
-rw-r--r--org.eclipse.jubula.documentation/manual/en/tex/Concepts/DB/singleUser.tex2
-rw-r--r--org.eclipse.jubula.documentation/manual/en/tex/Concepts/DB/structure.tex17
-rw-r--r--org.eclipse.jubula.documentation/manual/en/tex/Concepts/Reusability/CONTENT.tex23
-rw-r--r--org.eclipse.jubula.documentation/manual/en/tex/Concepts/Reusability/abstract.tex17
-rw-r--r--org.eclipse.jubula.documentation/manual/en/tex/Concepts/Reusability/compnames.tex36
-rw-r--r--org.eclipse.jubula.documentation/manual/en/tex/Concepts/Reusability/datasets.tex16
-rw-r--r--org.eclipse.jubula.documentation/manual/en/tex/Concepts/Reusability/external.tex15
-rw-r--r--org.eclipse.jubula.documentation/manual/en/tex/Concepts/Reusability/intro.tex24
-rw-r--r--org.eclipse.jubula.documentation/manual/en/tex/Concepts/Reusability/moving.tex20
-rw-r--r--org.eclipse.jubula.documentation/manual/en/tex/Concepts/Reusability/references.tex21
-rw-r--r--org.eclipse.jubula.documentation/manual/en/tex/Concepts/Reusability/specexec.tex67
-rw-r--r--org.eclipse.jubula.documentation/manual/en/tex/Concepts/Reusability/terms.tex32
-rw-r--r--org.eclipse.jubula.documentation/manual/en/tex/Concepts/Strategy/CONTENT.tex10
-rw-r--r--org.eclipse.jubula.documentation/manual/en/tex/Concepts/Strategy/bottomup.tex6
-rw-r--r--org.eclipse.jubula.documentation/manual/en/tex/Concepts/Strategy/intro.tex9
-rw-r--r--org.eclipse.jubula.documentation/manual/en/tex/Concepts/Strategy/refactoring.tex13
-rw-r--r--org.eclipse.jubula.documentation/manual/en/tex/Concepts/Strategy/topdown.tex6
-rw-r--r--org.eclipse.jubula.documentation/manual/en/tex/Concepts/Testing/info.tex6
-rw-r--r--org.eclipse.jubula.documentation/manual/en/tex/Concepts/Testlogic/CONTENT.tex2
-rw-r--r--org.eclipse.jubula.documentation/manual/en/tex/Concepts/Testlogic/eventhandler.tex4
-rw-r--r--org.eclipse.jubula.documentation/manual/en/tex/Concepts/Testlogic/execution.tex11
-rw-r--r--org.eclipse.jubula.documentation/manual/en/tex/Concepts/Testlogic/job.tex2
-rw-r--r--org.eclipse.jubula.documentation/manual/en/tex/Concepts/Testlogic/objectmapping.tex19
-rw-r--r--org.eclipse.jubula.documentation/manual/en/tex/Concepts/Testlogic/projects.tex2
-rw-r--r--org.eclipse.jubula.documentation/manual/en/tex/Concepts/Testlogic/recording.tex17
-rw-r--r--org.eclipse.jubula.documentation/manual/en/tex/Concepts/Testlogic/teststep.tex2
-rw-r--r--org.eclipse.jubula.documentation/manual/en/tex/Concepts/Working/CONTENT.tex6
-rw-r--r--org.eclipse.jubula.documentation/manual/en/tex/Concepts/Working/bxenvironments.tex27
-rw-r--r--org.eclipse.jubula.documentation/manual/en/tex/Introduction/Intro/approaches.tex2
-rw-r--r--org.eclipse.jubula.documentation/manual/en/tex/Samples/Intro/accessing.tex10
-rw-r--r--org.eclipse.jubula.documentation/manual/en/tex/Samples/Meters/CONTENT.tex38
-rw-r--r--org.eclipse.jubula.documentation/manual/en/tex/Samples/Meters/test.tex4
 diff --git a/org.eclipse.jubula.documentation/manual/en/tex/BestPractices/Eventhandlers/global.tex b/org.eclipse.jubula.documentation/manual/en/tex/BestPractices/Eventhandlers/global.texindex b66b3f06a..df9fab38c 100644--- a/org.eclipse.jubula.documentation/manual/en/tex/BestPractices/Eventhandlers/global.tex+++ b/org.eclipse.jubula.documentation/manual/en/tex/BestPractices/Eventhandlers/global.tex@@ -1,4 +1,4 @@-When automated tests are running, it is important to ensure that an error in the test will not result in the rest of the test not running. To do this, the \app{} team adds general \gdehandlers{} to each use case, at the very top level of the use case. +When automated tests are running, it is important to ensure that an error in the test will not result in the rest of the test not running. To do this, we recommend adding general \gdehandlers{} to each use case, at the very top level of the use case. The aim of adding \gdehandlers{} here is: \begin{enumerate}@@ -28,14 +28,17 @@ they are activated when an error occurs. \begin{enumerate} \item Open a use case in the \gdtestcaseeditor{}. Remember that each use case should be independent, and entirely contained in one single top level \gdcase{} \bxpref{BPKeywordSuites}. -\item Add the \bxname{Action Error} \gdcase{} to the use case as an \gdehandler{}. Specify \bxname{Action Error} as the error type, and \bxname{return} as the reentry type. +\item Add the \bxname{Action Error} \gdcase{} to the use case as an \gdehandler{} \bxpref{customizedehandler}. Specify \bxname{Action Error} as the error type, and \bxname{return} as the reentry type. \item Add the \bxname{Check Failed} \gdcase{} to the use case as an \gdehandler{}. Specify \bxname{Check Failed} as the error type, and \bxname{continue} as the reentry type. \item Add the \bxname{Component Not Found} \gdcase{} to the use case as an \gdehandler{}. Specify \bxname{Component Not Found} as the error type, and \bxname{return} as the reentry type. \item Add the \bxname{Configuration Error} \gdcase{} to the use case as an \gdehandler{}. Specify \bxname{Configuration Error} as the error type, and \bxname{return} as the reentry type. -\item Now, any error in this use case (which is not handled by a local \gdehandler{} within the use case) will result in one of these \gdehandlers{} being activated. \bxname{Check failed} errors will mean that the test continues. \bxname{Action errors}, \bxname{Component not found} and \bxname{Configuration errors} will provoke a restart of the \gdaut{}. The test execution leaves the branch in which the \gdehandler{} was nested (the use case) and carries on at the next \gdcase{} (use case) or \gdsuite{}. -\bxtipp{The \bxname{app\_startup} \gdcase{} is important at the beginning of each use case in case the \gdaut{} has just been restarted \bxpref{BPKeywordSuites}. }-\item Carry out these steps for each use case as you create it. \end{enumerate} +Now, any error in this use case (which is not handled by a local \gdehandler{} within the use case) will result in one of these \gdehandlers{} being activated. \bxname{Check failed} errors will mean that the test continues. \bxname{Action errors}, \bxname{Component not found} and \bxname{Configuration errors} will provoke a restart of the \gdaut{}. The test execution leaves the branch in which the \gdehandler{} was nested (the use case) and carries on at the next \gdcase{} (use case) or \gdsuite{}. +\bxtipp{The \bxname{app\_startup} \gdcase{} is important at the beginning of each use case in case the \gdaut{} has just been restarted \bxpref{BPKeywordSuites}. }++Carry out these steps for each use case as you create it. ++ In this way, unexpected errors can be dealt with in a way that allows them to be identified later on. The test does not stop at the error, but tries to carry on at the next relevant point. This is the reason why use cases should be independent from each other -- to stop further errors occurring. diff --git a/org.eclipse.jubula.documentation/manual/en/tex/BestPractices/Eventhandlers/local.tex b/org.eclipse.jubula.documentation/manual/en/tex/BestPractices/Eventhandlers/local.texindex a23547b8c..89ca4de16 100644--- a/org.eclipse.jubula.documentation/manual/en/tex/BestPractices/Eventhandlers/local.tex+++ b/org.eclipse.jubula.documentation/manual/en/tex/BestPractices/Eventhandlers/local.tex@@ -1,8 +1,13 @@-Often, there are errors that occasionally occur at specific points in the test. A good example of this is a warning dialog that sometimes occurs when saving, for example. For errors that can be expected in some way, you can add \gdehandlers{} to the \gdcases{} that cause the error to deal with the error and carry on with the test without activating the global \gdehandlers{}.+Often, there are errors that occasionally occur at specific points in the test. A good example of this is a prompt dialog that sometimes occurs when saving, for example. For errors that can be expected in some way, you can add \gdehandlers{} to the \gdcases{} that cause the error to deal with the error and carry on with the test without activating the global \gdehandlers{}.+++You can use local \gdehandlers{} to specify a particular response to an error at this point -- e.g. if you have a check for the existence of a project in the \gddb{} and it fails, you may not want to continue with this test. ++You can also use local \gdehandlers{} to wait for, or create a state in the \gdaut{} that you require before the test can continue. In this case, you should structure your \gdcase{} so that it checks for the status you require. If this isn't the case, the \gdehandler{} is activated and takes the necessary steps to produce the status. Using the \bxname{retry} reentry type \bxpref{reentrytype}, you can specify that the failed \gdstep{} (the check) is retried after the \gdehandler{} has been executed. An example of this is below. \subsubsection{Dealing with occasional dialogs}-In the case of occasional dialogs, your \gdcase{} in the test should contain an action which checks that a certain component in the dialog does \bxname{not} exist on the screen (e.g.\bxname{Check Existence of Component in Warning Dialog}). If the component is indeed not visible, the test will continue normally. +In the case of occasional dialogs, your \gdcase{} in the test should contain an action which checks that the dialog does \textbf{not} exist (e.g.\bxname{Check Existence of Window} with the parameter \bxname{false}). If the dialog is not visible, the test will continue normally. -If the component is visible, an error occurs. Add an \gdehandler{} to the \bxname{Check Existence of Component in Warning Dialog} \gdcase{} that clicks e.g. the cancel button in the window and waits for the window to close. The \gdehandler{} should react to a \bxname{check failed} event, and should use \bxname{retry} as the reentry property. Once the window has closed, the failed \gdstep{} (check existence) will be carried out again. This time, the check will succeed, and the test will continue. The \gdstep{} will be marked as successful on retry. +If the dialog is present, an error occurs. Add an \gdehandler{} to the \bxname{Check Existence of Window} \gdcase{} that clicks e.g. the cancel button in the window and waits for the window to close. The \gdehandler{} should react to a \bxname{check failed} event, and should use \bxname{retry} as the reentry property. Once the window has closed, the failed \gdstep{} (check existence) will be carried out again. This time, the check will succeed, and the test will continue. The \gdstep{} will be marked as successful on retry. diff --git a/org.eclipse.jubula.documentation/manual/en/tex/BestPractices/Keywords/data.tex b/org.eclipse.jubula.documentation/manual/en/tex/BestPractices/Keywords/data.texindex dce7441cc..6bcd42436 100644--- a/org.eclipse.jubula.documentation/manual/en/tex/BestPractices/Keywords/data.tex+++ b/org.eclipse.jubula.documentation/manual/en/tex/BestPractices/Keywords/data.tex@@ -1,4 +1,4 @@-The rule of thumb for dealing with data is, like with keyword design, not to do anything twice. This means that you should set data that will not change and parameterize data that will change. +The rule of thumb for dealing with data is, like with keyword design, not to do anything twice. This means that you should set data that will not change \bxpref{TasksTestdataConcrete} and parameterize data that will change \bxpref{TasksTestdataReferences}. Keywords that enter text, select from trees and check boolean values are all likely to need referenced parameters so that you can specify each time you reuse the \gdcase{} what text to enter, what to select, and whether you expect a true or false result. diff --git a/org.eclipse.jubula.documentation/manual/en/tex/BestPractices/Keywords/keywords.tex b/org.eclipse.jubula.documentation/manual/en/tex/BestPractices/Keywords/keywords.texindex 6b505fa30..f47bd86fc 100644--- a/org.eclipse.jubula.documentation/manual/en/tex/BestPractices/Keywords/keywords.tex+++ b/org.eclipse.jubula.documentation/manual/en/tex/BestPractices/Keywords/keywords.tex@@ -11,13 +11,13 @@ So what is a keyword? A good example is \bxname{Login}. It is obvious from the n \item ub\_grc\_clickLeftSingle (no parameters) \end{itemize} -In this keyword, the two TEXT parameters from the replace text modules would be referenced as \bxshell{=USERNAME} and \bxshell{PASSWORD}.+In this keyword, the two TEXT parameters from the replace text modules would be referenced as \bxshell{=USERNAME} and \bxshell{PASSWORD} \bxpref{TasksTestdataReferences}. Any time you need to perform a login in your test, you can reuse this keyword and enter the specific use data each time. This has the advantage that your tests will be easy to read, and that any maintenance you need to do to this keyword can be done in one place. Other things that lend themselves well to being made into keywords are: \begin{itemize}-\item Synchronized clicks on buttons (e.g. wait for component, check enablement, click). +\item Synchronized clicks on buttons (e.g. wait for component, then check enablement, then click). \item Tab selections (e.g. Select Content Tab, Select Options Tab in Tools Dialog). \item Recurring workflows (e.g. carrying out a search). \item Anything that you use more than once.@@ -39,10 +39,11 @@ In designing your tests, it may sometimes occur to you that there is a level bet \begin{itemize} \item ub\_grc\_waitForComponent \item ub\_grc\_checkEnablement+\item ub\_grc\_checkEditability \item ub\_cti\_replaceText \end{itemize} -It is very likely that a test will have to enter various texts. The only difference for each case will be the text to enter and the component to enter it into. All other things (amount of time to wait for the component, the fact that the component should be enabled etc) will remain the same. A utility module to perform a synchronized replace text can solve this problem. It can be reused in \gdcases{} to replace the text on any component \bxpref{TasksCompNamesCheckbox} and only requires the text to enter as a parameter. +It is very likely that a test will have to enter various texts. The only difference for each case will be the text to enter and the component to enter it into. All other things (amount of time to wait for the component, the fact that the component should be enabled and editable etc.) will remain the same. A utility module to perform a synchronized replace text can solve this problem. It can be reused in \gdcases{} to replace the text on any component \bxpref{TasksCompNamesCheckbox} and only requires the text to enter as a parameter. Generally, it is worth making a utility module when the unbound module contains one or more parameters whose values will remain constant in your test (typically things like file paths, operators, path types etc.). The utility module can parameterize the data that will change (e.g. boolean values, text entries, what to check etc.) and make your test specification and maintanence quicker. diff --git a/org.eclipse.jubula.documentation/manual/en/tex/BestPractices/Keywords/suites.tex b/org.eclipse.jubula.documentation/manual/en/tex/BestPractices/Keywords/suites.texindex cfe66a924..b552d491a 100644--- a/org.eclipse.jubula.documentation/manual/en/tex/BestPractices/Keywords/suites.tex+++ b/org.eclipse.jubula.documentation/manual/en/tex/BestPractices/Keywords/suites.tex@@ -1,17 +1,10 @@ When it comes to executing tests, there are two important things to bear in mind when working with \app{}: \begin{itemize}-\item All the necessary keywords for a single \bxname{use case} should be grouped together in one \gdcase{}, which is named after the use case it tests. The use case should be complete -- it should not require any data or component names. This makes it much easier to add and remove whole use cases from \gdsuites{}. -\item Each use case should assume a well-defined state of the \gdaut{} and leave the \gdaut{} in a well-defined state. This is important for error handling later. It is a good idea to create a keyword called \bxname{app\_startup} which creates the right state for the \gdaut{}, and to use this keyword at the beginning of each use case (\bxfigref{UseCase}). +\item All the necessary keywords for a single \bxname{use case} should be grouped together in one \gdcase{}, which is named after the use case it tests. The use case should be complete -- it should not require any data or component names. This makes it much easier to add and remove whole use cases from \gdsuites{} and gives you a good overview of which use cases you have tested. +\item Each use case should assume (and create) a well-defined state of the \gdaut{} and leave the \gdaut{} in a well-defined state. This is important for error handling later. It is a good idea to create a keyword called \bxname{app\_startup} which creates the right state for the \gdaut{}, and to use this keyword at the beginning of each use case (\bxfigref{UseCase}). \bxtipp{The well-defined state of your \gdaut{} may be completely empty, or may contain test data. Deciding what data your test needs and what data it will create itself is an important part of an automation strategy.} \end{itemize} -%% \begin{figure}[h]-%% \begin{center}-%% \includegraphics{BestPractices/Keywords/PS/UseCase}-%% \caption{Example Use Case}-%% \label{UseCase}-%% \end{center}-%% \end{figure} Use cases are then grouped together into \gdsuites{}. The \app{} team uses the following \gdsuites{} in their tests: \begin{itemize}@@ -20,17 +13,9 @@ Use cases are then grouped together into \gdsuites{}. The \app{} team uses the f \item WORK\_(INITIALS) \end{itemize} -The FULLTEST \gdsuite{} contains all of the executable \bxname{Use Cases} from the \gdproject{}. There can also be \gdcases{} which reproduce errors from the bug-tracking system, called \bxname{ticket tests}. Each ticket \gdcase{} is named with the ticket number to link it to the bug-tracking system (\bxfigref{TestSuiteStructure}). +The FULLTEST \gdsuite{} contains all of the executable \bxname{Use Cases} from the \gdproject{}. There can also be \gdcases{} which reproduce errors from the bug-tracking system, called \bxname{ticket tests}. Each ticket \gdcase{} can be linked to the bug-tracking system via its ID. -%% \begin{figure}[h]-%% \begin{center}-%% \includegraphics{BestPractices/Keywords/PS/TestSuiteStructure}-%% \caption{\gdsuite{} Structure}-%% \label{TestSuiteStructure}-%% \end{center}-%% \end{figure} --The FULLTEST\_BROKEN \gdsuite{} contains any use cases which are currently broken and which have been removed from the FULLTEST so as not to affect any test reports or statistics. Put tests in the broken \gdsuite{} if they have been broken for some time. Tests that are critical, or which should be fixed in the next build, can be left in the FULLTEST \gdsuite{}. +The FULLTEST\_BROKEN \gdsuite{} contains any use cases which are currently broken and which have been removed from the FULLTEST so as not to affect any test reports or statistics. Put tests in the broken \gdsuite{} if they have been broken for some time. Tests that are critical, or which should be fixed in the next build, should be left in the FULLTEST \gdsuite{}. The WORK \gdsuites{} can be used by testers as a sandbox to execute single use cases during specification, or to replay tests with the intention of watching the execution. diff --git a/org.eclipse.jubula.documentation/manual/en/tex/BestPractices/Naming/CONTENT.tex b/org.eclipse.jubula.documentation/manual/en/tex/BestPractices/Naming/CONTENT.texindex 259f51ad0..b20f7727b 100644--- a/org.eclipse.jubula.documentation/manual/en/tex/BestPractices/Naming/CONTENT.tex+++ b/org.eclipse.jubula.documentation/manual/en/tex/BestPractices/Naming/CONTENT.tex@@ -11,7 +11,7 @@ \label{BPComponentNames} \input{BestPractices/Naming/comps} -\subsection{Naming conventions for \gdsuites{}}+\subsection{Naming conventions for \gdsuites{} and \gdjobs{}} \gdhelpid{dialogTestsuiteNewContextId}{New Test Suite Dialog} \label{BPTestSuiteNames} \input{BestPractices/Naming/suites}diff --git a/org.eclipse.jubula.documentation/manual/en/tex/BestPractices/Naming/cases.tex b/org.eclipse.jubula.documentation/manual/en/tex/BestPractices/Naming/cases.texindex 4d23be106..25b2a19cc 100644--- a/org.eclipse.jubula.documentation/manual/en/tex/BestPractices/Naming/cases.tex+++ b/org.eclipse.jubula.documentation/manual/en/tex/BestPractices/Naming/cases.tex@@ -14,4 +14,4 @@ You should name your \gdcases{} so that it is clear from the name what the \gdca The \gdcase{} names do not have to exhaustively describe the component, or where it is in the \gdaut{} -- using categories for the different areas of your \gdaut{} saves you having to do this \bxpref{BPCategories}. The aim with naming your \gdcases{} is to make your tests readable and easy to understand. -You do not have to write \gdcase{} names in CamelCase or with underscores -- \gdcase{} names are not used in the command line client, so there is no problem if they have spaces in them. +You do not have to write \gdcase{} names in CamelCase or with underscores -- \gdcase{} names are not used in the test executor, so there is no problem if they have spaces in them. diff --git a/org.eclipse.jubula.documentation/manual/en/tex/BestPractices/Naming/comps.tex b/org.eclipse.jubula.documentation/manual/en/tex/BestPractices/Naming/comps.texindex d10309f2c..b8feb193b 100644--- a/org.eclipse.jubula.documentation/manual/en/tex/BestPractices/Naming/comps.tex+++ b/org.eclipse.jubula.documentation/manual/en/tex/BestPractices/Naming/comps.tex@@ -8,13 +8,13 @@ So the components in a login dialog could be named: \item \bxname{LoginDialog\_Username\_cti} \item \bxname{LoginDialog\_Password\_cti} \item \bxname{LoginDialog\_Language\_cbx}-\item \bxname{LoginDialog\_OK\_bt}-\item \bxname{LoginDialog\_Cancel\_bt}+\item \bxname{LoginDialog\_OK\_btn}+\item \bxname{LoginDialog\_Cancel\_btn} \end{itemize} \bxtipp{Using the \bxname{New Component Name} feature in \app{}, \bxpref{TasksCreateNewCompName}, you can create component names for your \gdaut{} at the beginning to set conventions the whole team should use.} -The table below gives the abbreviations used by the \app{} team to distinguish between component types. +The table below gives some common abbreviations to distinguish between component types. \begin{table} \centeringdiff --git a/org.eclipse.jubula.documentation/manual/en/tex/BestPractices/Naming/suites.tex b/org.eclipse.jubula.documentation/manual/en/tex/BestPractices/Naming/suites.texindex 3985a2e7a..0e77c6fad 100644--- a/org.eclipse.jubula.documentation/manual/en/tex/BestPractices/Naming/suites.tex+++ b/org.eclipse.jubula.documentation/manual/en/tex/BestPractices/Naming/suites.tex@@ -1,3 +1,2 @@-\gdsuite{} names should not contain any special characters or spaces. As \gdsuites{} are entered via the command line client, it is important to have names that are easy to enter into a command line under any system. +\gdsuite{} and \gdjob{} names should not contain any special characters or spaces. As \gdsuites{} and \gdjobs{} are entered via the test executor, it is important to have names that are easy to enter into a command line under any system. -The \app{} team uses four main types of \gdsuite{} to execute their tests, \bxname{FULLTEST}, \bxname{FULLTEST\_BROKEN}, \bxname{TICKET\_} and \bxname{WORK\_}. The function of these \gdsuites is explained in the section on structuring \gdsuites{} \bxpref{BPKeywordSuites}. diff --git a/org.eclipse.jubula.documentation/manual/en/tex/BestPractices/Structure/tcb.tex b/org.eclipse.jubula.documentation/manual/en/tex/BestPractices/Structure/tcb.texindex 10e96beef..f8776494b 100644--- a/org.eclipse.jubula.documentation/manual/en/tex/BestPractices/Structure/tcb.tex+++ b/org.eclipse.jubula.documentation/manual/en/tex/BestPractices/Structure/tcb.tex@@ -1,6 +1,6 @@ We recommend using categories \bxpref{TasksTCCats} to structure the \gdtestcasebrowser{}. This makes your keywords easier to find when you are creating tests. -The \app{} team use two main categories to organize the \gdtestcasebrowser{}: executable tests and modules. +We recommend using two main categories to organize the \gdtestcasebrowser{}: executable tests and modules. \subsubsection{Executable tests} The \bxname{executable test} category (\bxfigref{ExecutableCategory}) contains the following:diff --git a/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Architecture/CONTENT.tex b/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Architecture/CONTENT.texindex b945685d1..d2fc123a6 100644--- a/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Architecture/CONTENT.tex+++ b/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Architecture/CONTENT.tex@@ -10,13 +10,13 @@ \input{Concepts/Architecture/overview} -\subsection{\jbclient}+\subsection{\ite{}} \input{Concepts/Architecture/client} -\subsection{\gdagent}+\subsection{\gdagent{}} \input{Concepts/Architecture/server} -\subsection{Working with the client and \gdagent on different machines}+\subsection{Working with the \ite{} and \gdagent on different machines} \input{Concepts/Architecture/diffmachines} diff --git a/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Architecture/client.tex b/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Architecture/client.texindex 823067b07..442326817 100644--- a/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Architecture/client.tex+++ b/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Architecture/client.tex@@ -7,8 +7,9 @@ % User documentation % copyright by BREDEX GmbH 2004 % ---------------------------------------------------------\index{Client}-The \jbclient{} is the interface between you and the \gdaut{}. It provides you with browsers to see \gdcases{} and \gdsuites{}, and editors to modify them. +\index{ITE}+\index{Integrated Test Environment}+The \ite{} is the interface between you and the \gdaut{}. It provides you with browsers to see \gdcases{} and \gdsuites{}, and editors to modify them. In the client, you specify your tests without any programming. \app{} lets you write tests modularly, structure them to fit your needs, and easily change them to follow developments in the \gdaut{}. diff --git a/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Architecture/diffmachines.tex b/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Architecture/diffmachines.texindex eddcbe0c3..ecb81bb1c 100644--- a/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Architecture/diffmachines.tex+++ b/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Architecture/diffmachines.tex@@ -1,4 +1,4 @@-You can install the client on any machine in the network, and then install the \gdagent on various other machines in the network. +You can install the \ite{} on any machine in the network, and then install the \gdagent on various other machines in the network. This scenario is shown in the following diagram (\bxfigref{diffmachines}). @@ -10,7 +10,7 @@ This scenario is shown in the following diagram (\bxfigref{diffmachines}). \end{center} \end{figure} -Within the \app{} client, you can define configurations for your \gdaut{}. The configurations specify where \app{} should look for the \gdaut{} jar or exe file, the JRE binary etc., and on which machine it should look. +Within the \ite{}, you can define configurations for your \gdaut{}. The configurations specify where \app{} should look for the \gdaut{} jar or exe file, the JRE binary etc., and on which machine it should look. \app{} lets you specify different \gdagent{} hosts and port numbers to connect to. diff --git a/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Architecture/overview.tex b/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Architecture/overview.texindex ff5fb5ec7..ba2bf14ee 100644--- a/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Architecture/overview.tex+++ b/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Architecture/overview.tex@@ -10,10 +10,10 @@ \index{Client} \index{Server} -\app{} is a client-server application: +\app{} is a client-server application. We refer to the client part as the Integrated Test Environment or \ite{}, and the server component as the \gdagent{}.: \begin{description}-\item[The \jbclient{}]{is where tests are specified and evaluated.}-\item [The server (\gdagent){}]{controls the application under test (\gdaut{}) and executes the specified tests. }+\item[The \ite{}]{is where tests are specified and evaluated.}+\item [The \gdagent{}]{controls the application under test (\gdaut{}) and executes the specified tests. } \end{description} - You can install the client and \gdagent on different machines; even on different platforms. This lets you specify and run your tests on different machines, and means that you can run the same test on different platforms. + You can install the \ite{} and \gdagent{} on different machines; even on different platforms. This lets you specify and run your tests on different machines, and means that you can run the same test on different platforms. diff --git a/org.eclipse.jubula.documentation/manual/en/tex/Concepts/DB/singleUser.tex b/org.eclipse.jubula.documentation/manual/en/tex/Concepts/DB/singleUser.texindex 387700128..669f69d9c 100644--- a/org.eclipse.jubula.documentation/manual/en/tex/Concepts/DB/singleUser.tex+++ b/org.eclipse.jubula.documentation/manual/en/tex/Concepts/DB/singleUser.tex@@ -8,7 +8,7 @@ % copyright by BREDEX GmbH 2004 % -------------------------------------------------------- If you work on a single-user database, only one tester can work on a specific \gdproject{} at a time. -This also applies to the Command Line Client -- the standard client and the Command Line Client cannot access a single-user database at the same time.+This also applies to the test executor -- the \ite{} and the test executor cannot access a single-user database at the same time. This method reduces the complexity of the system and its configuration, and should really only be used for demo purposes. diff --git a/org.eclipse.jubula.documentation/manual/en/tex/Concepts/DB/structure.tex b/org.eclipse.jubula.documentation/manual/en/tex/Concepts/DB/structure.texindex 678539ce6..40195d790 100644--- a/org.eclipse.jubula.documentation/manual/en/tex/Concepts/DB/structure.tex+++ b/org.eclipse.jubula.documentation/manual/en/tex/Concepts/DB/structure.tex@@ -8,21 +8,12 @@ % copyright by BREDEX GmbH 2004 % -------------------------------------------------------- \index{Database}-\app{} possesses a \gddb{}-independent data storage scheme using the- \bxname{Hibernate} service for \bxname{Java} objects.-\bxname{Hibernate} provides a layer of abstraction between the application- and the underlying storage mechanism, allowing for portability -and simplified upgradability.+\app{} uses \bxname{Eclipse Link} as an object relational mapping layer. -\bxname{HSQL DB} and \bxname{Oracle 9i} have been thoroughly- tested to work with \app{}; \bxname{HSQL DB} for the single-user \gddb{}, -and \bxname{Oracle 9i} for the multi-user \gddb{}. -Other \gddb{} solutions supported by \bxname{Hibernate} may also be -used as a \gddb{}, though these have not been tested by our team. -See- \htmladdnormallink{http://www.hibernate.org}{http://www.hibernate.org}-for a detailed list of \bxname{Hibernate}-supported databases. +\app{} is tested with \bxname{Oracle}.+Other \gddb{} solutions supported by \bxname{Eclipse Link} may also be +used as a \gddb{}, though these have not been tested by our team. diff --git a/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Reusability/CONTENT.tex b/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Reusability/CONTENT.texdeleted file mode 100644index f08c0b769..000000000--- a/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Reusability/CONTENT.tex+++ /dev/null@@ -1,23 +0,0 @@-% $Id: CONTENT.tex 12243 2010-09-21 13:40:10Z alexandra$-% Local Variables:-% ispell-check-comments: nil-% Local IspellDict: american-% End:-% ---------------------------------------------------------% User documentation-% copyright by BREDEX GmbH 2004-% ---------------------------------------------------------\index{References}-\index{Reusability}-\label{referenceconcepts}-%this is actually used - referenced from testlogic folder-\input{Concepts/Reusability/intro}--\subsection{References}-\input{Concepts/Reusability/references}--\subsection{Abstract components}-\input{Concepts/Reusability/abstract}--\subsection{Reassigning component names}-\input{Concepts/Reusability/compnames}diff --git a/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Reusability/abstract.tex b/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Reusability/abstract.texdeleted file mode 100644index e6d25d659..000000000--- a/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Reusability/abstract.tex+++ /dev/null@@ -1,17 +0,0 @@--\index{Components!Abstract}-\index{Abstract components}--Another way to make your \gdcases{} more reusable is to increase the amount of components they can test. For each action, you choose a component type. \app{} has three levels of components:-\begin{description}-\item [Abstract components]{are general, high-level components from which other components are derived. They are described in terms of what features a component has, e.g. graphics component, component with text. They group actions together which can all be executed on components of this type.}-\item [Concrete components]{are components which are available to all graphical toolkits, but which are restricted to a certain component type, e.g. combo box, list.}-\item [Toolkit specific components]{are the most specific components in \app{}. They are only available for certain toolkits. For example, a HTML link is a component which is only available in Web applications.}-\end{description}--We recommend that you specify your tests as abstractly as possible, and as concretely as necessary. If you want to create a \gdcase{} to click a button, it is better to use the abstract component \bxname{graphics component}. The \bxname{graphics component} also contains the \bxname{click} action, and has the advantage that the \gdcase{} can then be used on other components than buttons. If you want to select a cell from a table, however, you will have to use the concrete component \bxname{table}, because this is the highest level which offers this action. --The more abstract your specification, the more reusable your \gdcases{} are. Abstract specifications are also easier to maintain after changes in the user-interface. If the object mapping needs to be adapted to a change in the GUI, there is a larger chance that the new GUI-component can be mapped to the original specification if abstract components were used. ---diff --git a/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Reusability/compnames.tex b/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Reusability/compnames.texdeleted file mode 100644index 8e4aba472..000000000--- a/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Reusability/compnames.tex+++ /dev/null@@ -1,36 +0,0 @@-% $Id: compnames.tex 8161 2009-04-06 14:07:39Z alexandra$-% Local Variables:-% ispell-check-comments: nil-% Local IspellDict: american-% End:-% ---------------------------------------------------------% User documentation-% copyright by BREDEX GmbH 2004-% ---------------------------------------------------------\index{Component!Names!Reassigning}-\index{Reassigning!Component Names}-\index{View!Component Names}-\index{Component!Names!View}-\index{Names!Component!Reassigning}- \label{reassconcepts}-Once you have made your \gdcases{} reusable, you can add them to other \gdcases{}. -The component names you use can be \bxname{reassigned} when you reuse the \gdcase{} they are in. --This creates a new name for the component in the \gdomeditor{}, which can then be mapped to another component in the \gdaut{}. This means that you can use one \gdcase{} to test the same action on different components. So you can specify one \gdcase{} to click a button, and use it every time you want your test to click a button in the \gdaut{}.--%\bxtipp{You can only map components of the same type as the original name}--If you use abstract components, you increase the amount of components your \gdcase{} can be mapped to, which reduces redundancy and makes the test easier to maintain. --As with references, you can move component names one level up in the hierarchy by checking the box in the \gdcompnamesview{}. This means that the component name can also be overwritten at the next level, when that \gdcase{} is reused. --\begin{figure}-\begin{center}-\includegraphics{Concepts/PS/compnames}-\caption{\gdcompnamesview}-\label{compnames}-\end{center}-\end{figure}---diff --git a/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Reusability/datasets.tex b/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Reusability/datasets.texdeleted file mode 100644index 0c140aa4e..000000000--- a/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Reusability/datasets.tex+++ /dev/null@@ -1,16 +0,0 @@-% $Id: datasets.tex 2559 2006-07-26 08:35:50Z alexandra$-% Local Variables:-% ispell-check-comments: nil-% Local IspellDict: american-% End:-% ---------------------------------------------------------% User documentation-% copyright by BREDEX GmbH 2004-% ---------------------------------------------------------\index{View!Data Sets}-\index{Data Sets View}-\label{datasetsconcepts}--You can enter \emph{data sets} for parameters you have moved up to a \gdcase{}. Once you have used references in the \gdsteps{} or \gdcases{} nested in a \gdcase{}, these parameters become a part of this parent \gdcase{}. You can then enter one or more data sets for these parameters. The whole \gdcase{} will be executed once for each data set, allowing you to test more data without specifying a \gdcase{} for each set. --As with ordinary concrete parameter values, you can overwrite values in the \gddatasetsview{} when you reuse the \gdcase{}. \ No newline at end of filediff --git a/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Reusability/external.tex b/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Reusability/external.texdeleted file mode 100644index 43a99e11f..000000000--- a/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Reusability/external.tex+++ /dev/null@@ -1,15 +0,0 @@-% $Id: external.tex 4085 2006-12-05 10:47:50Z andreast$ -% Local Variables: -% ispell-check-comments: nil -% Local IspellDict: american -% End: -% -------------------------------------------------------- -% User documentation -% copyright by BREDEX GmbH 2004 -% -------------------------------------------------------- -\index{External Data} -\index{Excel File} - -\app{} also lets you use data from an external source (an Excel file). You can give the path to an Excel file containing data for your test in the \gdpropview{}. You can use an Excel file for data if you have used references in the \gdsteps{} in a \gdcase{}. - -You can enter the path to the Excel file in the \gdpropview{} for the \gdtestcaseeditor{} or for the \gdtestsuiteeditor{}. You can also overwrite the path to the Excel file when you reuse a \gdcase{}. \ No newline at end of filediff --git a/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Reusability/intro.tex b/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Reusability/intro.texdeleted file mode 100644index 256fc0973..000000000--- a/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Reusability/intro.tex+++ /dev/null@@ -1,24 +0,0 @@-%% % BREDEX LaTeX Template-%% % \documentclass is either bxreport'' or bxarticle''-%% % option is bxpaper-%% \documentclass{bxarticle}-%% % -----------------------------------------------------------------------%% \begin{document}-%% \title{}-%% \author{}-%% % \author*{Hauptautor}{Liste der Nebenautoren}-%% \maketitle-%% % -----------------------------------------------------------------------%% \bxversion{0.1}-%% %\bxdocinfo{STATUS}{freigegeben durch}{freigegeben am}{Verteilerliste}-%% \bxdocinfo{DRAFT}{}{}{}-%% % ------------------------------------------------------------------------%% \end{document}-\app{} lets you create tests by reusing \gdcases{}. Once you have created a \gdcase{} in \app{}, you can \bxname{reuse} it by adding it to other \gdcases{} and \gdsuites{}. --The more general a \gdcase{} is, the easier it is to reuse in a variety of different places. The more you reuse \gdcases{} in your \gdproject{}, the easier it is to maintain your tests. --\app{} offers various features to improve the reusability of \gdcases{}. These features save time, avoid redundancy and make the tests you create well-structured and flexible. Instead of writing separate \gdcases{} for similar test situations, you can reuse a general \gdcase{}, and change the data or the component it tests. --diff --git a/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Reusability/moving.tex b/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Reusability/moving.texdeleted file mode 100644index ea79c456b..000000000--- a/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Reusability/moving.tex+++ /dev/null@@ -1,20 +0,0 @@--When you enter a reference in a \gdstep{} instead of a concrete value, the parameter you write the reference for is automatically \emph{moved up} to the -\gdcase{} containing the \gdstep{} (the \bxname{parent \gdcase{}}). --You can see this parameter behind the \gdcase{} name in the \gdtestcaseeditor{}. If you select the \gdcase{} node from within the \gdtestcaseeditor{} you can also see the parameter in the \gdpropview{}. This parameter is now a parameter of this \gdcase{}. You can move this parameter higher up from this \gdcase{} by entering another reference in the \gdpropview{} for this \gdcase{}. The parameter will then automatically appear in the next parent \gdcase{} and so on. --It is important to remember, however, that parameters (and component names) -are only moved up one level at a time. That is, to be able to enter -parameter values in the highest \gdcase{} in a hierarchy, references must -have been entered for each nested \gdcase{} beneath it. --This is especially important in the \gdtestsuiteeditor{}, since only -the top-level \gdcase{} is accessible to be edited at this point. To be able -to enter parameter values for lower \gdcases{} at this point, their parameters -must have been moved up using references. -----diff --git a/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Reusability/references.tex b/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Reusability/references.texdeleted file mode 100644index cccb8762d..000000000--- a/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Reusability/references.tex+++ /dev/null@@ -1,21 +0,0 @@-% $Id: references.tex 8161 2009-04-06 14:07:39Z alexandra$-% Local Variables:-% ispell-check-comments: nil-% Local IspellDict: american-% End:-% ---------------------------------------------------------% User documentation-% copyright by BREDEX GmbH 2004-% -------------------------------------------------------- -\index{References}-\index{Parameter!References}-\label{referencesconcepts}--The first way to make \gdcases{} reusable is to use placeholders for the data in them. Instead of specifying concrete parameter values in \gdsteps{}, you can use references for values that will change each time you reuse the \gdcase{}. These references act as placeholders for values to be inserted later. --The referenced parameter becomes a parameter of the parent \gdcase{}, and a value for it can be entered at the \gdcase{} level. --The advantage of using references is that a value is not fixed for a particular \gdcase{}. Instead of creating a new \gdcase{} for each different username, for example, you can have one \gdcase{} which can contain all the usernames you want to test as its data. --Using references also means that you can translate your data, you can use external data from an Excel file, and you can run the same \gdcase{} multiple times with different \bxname{data sets}. -diff --git a/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Reusability/specexec.tex b/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Reusability/specexec.texdeleted file mode 100644index 6ac2fb508..000000000--- a/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Reusability/specexec.tex+++ /dev/null@@ -1,67 +0,0 @@-% $Id: specexec.tex 4493 2007-02-08 09:58:18Z mike$-% Local Variables:-% ispell-check-comments: nil-% Local IspellDict: american-% End:-% ---------------------------------------------------------% User documentation-% copyright by BREDEX GmbH 2004-% ---------------------------------------------------------\index{Specification!Names}-\index{Execution!Names}-\index{Names!Specification}-\index{Names!Execution}-\index{Component!Names!Reassigning}-\index{Reassigning!Component Names}-\index{Names!Component!Reassigning}-\index{Color Coding}-\index{Master Template}-\label{specexec}--Specification occurs in the \gdtestcasebrowser{}, \gdmarpar{../../../share/PS/testCase}{specified \gdcase{}}, \gdtestcaseeditor{} and its support views. A specified \gdcase{} is a \emph{master template}. --Master templates can be reused in two ways: --\begin{itemize}-\item They can be added to a \gdsuite{} (in the \gdtestsuiteeditor{}). -\item They can be nested in another \gdcase{} (in the \gdtestcaseeditor{}). -\end{itemize}--\gdcases{} show a small arrow when they are reused to show that they are only a reference to the master template. -\gdmarpar{../../../share/PS/testCaseRef}{reused \gdcase}--%See the diagram in the \bxcaption{User Interface} chapter (\bxfigref{specexec}) -%for details on where specification and reuse occur. --\subsubsection{Modifying Reused \gdcases}-You can modify reused \gdcases{} in three ways:-\begin{itemize}-\item You can change the data they test by overwriting any previously entered parameter values \bxpref{referencetasks}. This is only possible if you have moved the parameters up using references in the \gdsteps{}. -\item You can change the component they test by reassigning the component names \bxpref{reass}. In this way, a single \gdcase{} can execute the same action on different components. -\item You can change the \gdcase{} name. \gdcases{} have both \emph{specification} and \emph{execution} -names. The specification name is the name of the master template, and you can overwrite this each time you reuse a \gdcase{}. -\end{itemize}--Until the data or \gdcase{} name is overwritten in a reused \gdcase{}, any changes to the data or name in the master template will be carried through to all places where you have reused the \gdcase{}. If you have overwritten data or the \gdcase{} name in a reused \gdcase{}, the reused \gdcase{} will no longer be affected when the data or name in the master template changes. ---\subsubsection{Foundations}-\app{} is a flexible program, allowing data values to be changed even after -specification. However, in order to preserve test functionality, you cannot alter the names of references in a -\gdstep{} or \gdcase{} if its parent \gdcase{} is nested in another \gdcase{}. --That is, the references in the child \gdcase{} are part of the \textbf{foundation} of the parent-\gdcase{}. This means that the references in the nested \gdcase{} -may not be changed, since modifications will change the foundation on which -the parent \gdcase{} is built. This may adversely -affect the test by making the other \gdcase{} unusable. --However, there is a way of altering \gdsteps{} and references in reused -\gdcases{}. See the section on modifying reused \gdcases{} -\bxpref{overwritingreused} in \bxcaption{Tasks} for more details. --%Reference values, however, may be edited at any time, as long as their -%eference has been carried through the hierarchy to the \gdcase to be -%edited. In the \gdtestsuitebrowser{}, for example, only values in the -%top-level \gdcase can be edited. -diff --git a/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Reusability/terms.tex b/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Reusability/terms.texdeleted file mode 100644index aa04344c0..000000000--- a/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Reusability/terms.tex+++ /dev/null@@ -1,32 +0,0 @@-% $Id: terms.tex 2559 2006-07-26 08:35:50Z alexandra$-% Local Variables:-% ispell-check-comments: nil-% Local IspellDict: american-% End:-% ---------------------------------------------------------% User documentation-% copyright by BREDEX GmbH 2004-% ---------------------------------------------------------\index{Parameter!Values}-\index{Parameter}-\index{References}-\index{Propagation}-\index{Foundation}-When we are talking about reusability, we will use the following terms:--\begin{description}-\item[Specification]{refers to the creation of test elements, most importantly \gdcases{}. A specified \gdcase{} is a \emph{master template}.}-\item[Reuse]{is the term used to describe the usage of a \gdcase{} in another \gdcase{} (nesting) or in a \gdsuite{}. }-\item[Overwriting]{is the process by which certain details or data are changed when a \gdcase{} is reused. Data which have been overwritten in a reused \gdcase{} will not change if the data in the master template change. }-\item[Parameters]{are the variables associated with a \gdstep{}.}-\item [Parameter values]{are the actual concrete integers or other inputs -which will be used when the test is executed.}-\item [References]{are placeholders for parameters. They allow concrete -parameter values to be specified at the next level (i.e. in the parent \gdcase{}. We refer to this as ''moving the parameter up''. References are preceded by -the reference symbol (default is $=$). }-\item[Foundation]{refers to the names of references which make up a -\gdcase{}. The names of references in any nested -\gdcases{} also count as the foundation. These details may not be altered, since this would lead to -instability.}-\end{description}-diff --git a/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Strategy/CONTENT.tex b/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Strategy/CONTENT.texindex fea20e78f..98ee2d02b 100644--- a/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Strategy/CONTENT.tex+++ b/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Strategy/CONTENT.tex@@ -9,17 +9,11 @@ % -------------------------------------------------------- \input{Concepts/Strategy/intro} -\subsection{Bottom-up}+\subsection{Writing modules in advance} \input{Concepts/Strategy/bottomup} -\subsection{Top-down}-\label{topdownconcepts}+\subsection{Creating modules from existing \gdcases{}} \input{Concepts/Strategy/topdown} \subsection{Choosing a method} \input{Concepts/Strategy/choose}--\subsection{Refactoring \gdcases{}}-\gdhelpid{dialogTestcaseExtractContextId}{Extract Test Case Dialog}-\input{Concepts/Strategy/refactoring}-diff --git a/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Strategy/bottomup.tex b/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Strategy/bottomup.texindex f14aea5fd..a25eae385 100644--- a/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Strategy/bottomup.tex+++ b/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Strategy/bottomup.tex@@ -7,13 +7,13 @@ % User documentation % copyright by BREDEX GmbH 2004 % ---------------------------------------------------------Bottom-up design approaches the testing process in a modular fashion. -Small ''building blocks'' (the \gdcases{} in \app{}) are specified in a general or abstract way, making them easy to adapt and reuse. +If you can identify which reusable modules a test will require in advance, then you can specify them in a general or abstract way, making them easy to adapt and reuse. + These small units are used to construct other modules or building blocks, which are more adapted to the task at hand. Concrete details can be added as needed. One of the advantages of this approach is that tests are flexible and easy to maintain, since a change made at a central point can update many places where that \gdcase{} has been reused. Tests are also generally more efficient, because time is not wasted specifying what is essentially the same \gdcase{} over and over again. -The difficulty with bottom-up testing is that it requires a good knowledge of the structure of the test -- you have to know which \gdcases{} are going to be required multiple times, and this is often not easy to recognize at the beginning of testing. +The difficulty with this approach testing is that it requires a good knowledge of the structure of the test -- you have to know which \gdcases{} are going to be required multiple times, and this is often not easy to recognize at the beginning of testing. diff --git a/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Strategy/intro.tex b/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Strategy/intro.texindex 63755dd3d..0bf44acf2 100644--- a/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Strategy/intro.tex+++ b/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Strategy/intro.tex@@ -7,11 +7,6 @@ % User documentation % copyright by BREDEX GmbH 2004 % -------------------------------------------------------- -\index{Top-Down Specification} -\index{Bottom-Up Specification} -\index{Specification!Approaches!Top-Down} -\index{Specification!Approaches!Bottom-Up} -\app{} supports both bottom-up and top-down testing. You can even use both methods in the same \gdproject{}, and often, you can easily change between the two. -The following sections explain a little about each approach, and its advantages and disadvantages. -The best method to choose will depend on the size and type of the \gdproject{}, the stage of testing, the \gdaut{} and your personal preferences. \ No newline at end of file+\app{} supports modular testing. You can either create modules in advance and combine them to make larger \gdcases{}, or you can create modules from existing \gdcases{} when you realize you need them. + diff --git a/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Strategy/refactoring.tex b/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Strategy/refactoring.texdeleted file mode 100644index 61cbdf3c2..000000000--- a/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Strategy/refactoring.tex+++ /dev/null@@ -1,13 +0,0 @@- % $Id: refactoring.tex 6515 2008-02-18 11:33:01Z alexandra$-% Local Variables:-% ispell-check-comments: nil-% Local IspellDict: american-% End:-% ---------------------------------------------------------% User documentation-% copyright by BREDEX GmbH 2004-% ---------------------------------------------------------\index{Refactoring}-As well as supporting both bottom-up and top-down testing, \app{} lets you change your specification from top-down to bottom-up. If you realize that a certain part of a \gdcase{} could actually be used as a \gdcase{} of its own -- i.e. it would be worth reusing it, you can ''extract'' a new \gdcase{} from it. --This means that you can create ''building blocks'' from other \gdcases{}, making it unimportant if you realize at a later point that parts of a test would be better if they were specified bottom-up. diff --git a/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Strategy/topdown.tex b/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Strategy/topdown.texindex 55cc191ce..0485f7b3c 100644--- a/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Strategy/topdown.tex+++ b/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Strategy/topdown.tex@@ -8,12 +8,12 @@ % copyright by BREDEX GmbH 2004 % -------------------------------------------------------- -Top-down testing is (at least initially) a more intuitive method of specification. -To specify a test top-down, you follow the steps in the same way as if you were carrying out the test yourself. -Each \gdstep{} is specified for the current purpose, and contains all the necessary details (e.g. data). +It is often initially more intuitive to start writing a test in a linear fashion, adding steps as necessary. Each step is specified for the current purpose, and contains all the necessary details (e.g. data). The possible problem with this method is that similar or identical parts are often separately and multiply specified, which means that making changes at a later point can be difficult and time-consuming. +To avoid this, \app{} lets you extract \gdcases{} from other \gdcases{} to combine them into reusable modules \bxpref{TasksEditorExtract}. +diff --git a/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Testing/info.tex b/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Testing/info.texindex 8e877f562..fcd526ef2 100644--- a/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Testing/info.tex+++ b/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Testing/info.tex@@ -1,8 +1,8 @@ \subsubsection{Actions} -\app{}supports ''high-level'' actions. By this we mean that some of the actions which can be chosen for a component actually carry out a number of actions. This makes the creation of \gdcases{} easier and quicker, and makes them more understandable. +\app{} supports ''high-level'' actions. By this we mean that some of the actions which can be chosen for a component actually carry out a number of actions. This makes the creation of \gdcases{} easier and quicker, and makes them more understandable. -For example, \app{} offers 2 actions to enter text into a text field. The action \bxname{Replace Text} selects the whole text in the component and then enters the text input. This effectively overwrites any text which was already in the component. The \bxname{Input Text} action clicks once in the component and then enters the text, which means that any text previously in the component remains. +For example, \app{} offers two actions to enter text into a text field. The action \bxname{Replace Text} selects the whole text in the component and then enters the text input. This effectively overwrites any text which was already in the component. The \bxname{Input Text} action clicks once in the component and then enters the text, which means that any text previously in the component remains. Another example is the selection and navigation through trees and menus. Like a human tester, \app{} works using the path to the item to select, and doesn't first have to select the individual sub-items in the path. @@ -13,7 +13,7 @@ When writing tests, it helps to be aware of things that a human tester does impl \subsubsection{Test execution} \app{} generally executes tests on your \gdaut{} by sending real clicks and key presses, in the same way that a manual tester would. This means that a \app{} test will give you the same results as a manual test -- if a menu is disabled, an item can't be selected and so on. -In the cases where real clicks and key presses can't be sent, \app{} ensures thatonly actions which would be possible for a user can be completed in a test. +%In the cases where real clicks and key presses can't be sent, \app{} ensures that only actions which would be possible for a user can be completed in a test. Once clicks and key presses have been sent, \app{} waits for confirmation from the \gdaut{} that they have arrived (manual testers use their eyes, \app{} uses confirmers). diff --git a/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Testlogic/CONTENT.tex b/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Testlogic/CONTENT.texindex f8f968364..3d4601ff4 100644--- a/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Testlogic/CONTENT.tex+++ b/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Testlogic/CONTENT.tex@@ -25,7 +25,7 @@ \input{Concepts/Testlogic/projects} \section{Reusability}-\input{Concepts/Reusability/CONTENT}+\input{Concepts/Testlogic/reusability} \section{Multi-lingual testing} \input{Concepts/Testlogic/languages}diff --git a/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Testlogic/eventhandler.tex b/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Testlogic/eventhandler.texindex 806e1c39c..c478c5264 100644--- a/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Testlogic/eventhandler.tex+++ b/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Testlogic/eventhandler.tex@@ -9,10 +9,10 @@ % -------------------------------------------------------- \index{Event Handler} -\label{errortypes} + \app{} offers \gdehandlers{} to react to errors during test execution and to continue the test in a way you define. -An \gdehandler{} \gdmarpar{../../../share/PS/EventHandler}{\gdehandler} is a \gdcase{} used with a special function. It is only executed when a certain error occurs. There are four different types of error in \app{}, and each \gdcase{} can have an \gdehandler{} for each error type. You can specify different reactions to each different error type, so that serious errors can stop the test, but unimportant errors will not affect the execution. +An \gdehandler{} \gdmarpar{../../../share/PS/EventHandler}{\gdehandler} is a \gdcase{} used with a special function. It is only executed when a certain type of error occurs. There are four different types of error in \app{}, and each \gdcase{} can have an \gdehandler{} for each error type. You can specify different reactions to each different error type, so that serious errors can stop the test, but unimportant errors will not affect the execution. Because \gdehandlers{} are normal \gdcases{}, they can also contain \gdehandlers{}, can do any of the things that a normal \gdcase{} can do. The only restriction is that you cannot add a \gdcase{} to itself as an \gdehandler{}. diff --git a/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Testlogic/execution.tex b/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Testlogic/execution.texindex c1941e329..f0608586f 100644--- a/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Testlogic/execution.tex+++ b/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Testlogic/execution.tex@@ -7,16 +7,9 @@ % User documentation % copyright by BREDEX GmbH 2004 % ---------------------------------------------------------\index{Results!XML and HTML Reports}-To be able to execute a test, you must have:-\begin{itemize}-\item created a \gdsuite{} and added \gdcases{} to it.-\item defined and configured an \gdaut{} for the \gdproject{}. -\item object mapped the components from the \gdsuite{}. -\item added any necessary test data for the language you want to test. -\end{itemize} -You can follow the execution in the \gdtestresultview{} and you can opt to produce HTML and XML result reports. +The prerequisites for test execution are covered in the previous chapter \bxpref{TestExec}. + \subsection{\gdstep{} execution} \app{} executes tests on the following basis: diff --git a/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Testlogic/job.tex b/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Testlogic/job.texindex 6552b796d..57904d710 100644--- a/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Testlogic/job.tex+++ b/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Testlogic/job.tex@@ -1,5 +1,5 @@ \index{Test Job} \label{ConceptsTestJob} -\gdjobs{} are the containers for \gdsuites{} which are to be executed in a sequence. A \gdjob{} can contain \gdsuites{} which test different \gdauts{} or different instances of the same \gdaut{} (with some restrictions, see the previous section \bxpref{TasksSwitchAUT} for details). Each \gdsuite{} in a \gdjob{} is bound to an \gdaut{} and specifies which \gdaut{} it will test based on the \gdaut{} ID: +\gdjobs{} are the containers for \gdsuites{} which are to be executed in a sequence. A \gdjob{} can contain \gdsuites{} which test different \gdauts{} or different instances of the same \gdaut{} (with some restrictions, see the previous section \bxpref{TasksSwitchAUT} for details). Each \gdsuite{} in a \gdjob{} is bound to an \gdaut{} and specifies which \gdaut{} it will test based on the \gdaut{} ID. diff --git a/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Testlogic/objectmapping.tex b/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Testlogic/objectmapping.texindex 12ceb6538..8d40d4d81 100644--- a/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Testlogic/objectmapping.tex+++ b/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Testlogic/objectmapping.tex@@ -45,26 +45,9 @@ Once you have collected the technical names from the \gdaut{}, you can ''assign' The fact that the object map is separate from the specification means that any changes that need to be made to update a test only need to be made once. \subsection{Locating components during test execution}-\app{} then uses this information to locate components when the test is running. The component recognition system used by \app{} uses various details about mapped components to find the right component during the test. The location of the component in the \gdaut{} hierarchy, the components near to it and the name of the component all play a role in component recognition. For each possible component, \app{} calculates the similarity to the originally mapped component. The component with the highest result is selected. + The component recognition system used by \app{} uses various details about mapped components to find the right component during the test. The location of the component in the \gdaut{} hierarchy, the components near to it and the name of the component all play a role in component recognition. For each possible component, \app{} calculates the similarity to the originally mapped component. The component with the highest result is selected. This method makes object mapping generally resilient to changes in the \gdaut{}. -%% \subsection{Changes in the user interface}-%% \label{abstractcomps1}-%% If a component moves in the user interface (either on the surface or in the hierarchy, \app{}'s component recognition method should find the component again. If the component changes type, then the recognition will depend on how large the change is. For example, changing a text field to a text pane should not alter the test, since both of these components are actually part of the same component in \app{}. -%% A larger change may result in having to remap the component. You can make maintenance easier by specifying your \gdsteps{} using abstract components, which can be mapped to a larger range of real components. --%% \subsection{Importing and exporting object mapping}-%% An additional feature of the \gdomeditor{} is the ability to export and import -%% the object mapping as an XML file (.map) for a \gdsuite{}. This -%% contributes to the reusability aspect of \app{}, since another -%% \gdproject{} using the same \gdaut{} can make use of this object mapping. --- ---- diff --git a/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Testlogic/projects.tex b/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Testlogic/projects.texindex 9e5cc34a1..235eea7b4 100644--- a/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Testlogic/projects.tex+++ b/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Testlogic/projects.tex@@ -10,6 +10,6 @@ \index{Project} \app{} organizes tests into \gdprojects{}. -A \gdproject{} is the top-level container in \app{}. \gdprojects{} contain \gdsuites{} and the details about the \gdauts{} to be tested by these \gdsuites{} (how to start them, in which language etc.). +A \gdproject{} is the top-level container in \app{}. \gdprojects{} contain runnable tests and the details about the \gdauts{} to be tested (how to start them, in which language etc.). You can work jointly on \gdprojects{} using the multi-user \gddb{}, and you can also share \gdprojects{} using the import and export functions. diff --git a/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Testlogic/recording.tex b/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Testlogic/recording.texindex 778cbc44e..34dea1175 100644--- a/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Testlogic/recording.tex+++ b/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Testlogic/recording.tex@@ -8,21 +8,15 @@ % copyright by BREDEX GmbH 2004 % -------------------------------------------------------- \index{Observation}-\index{Top-Down Specification}-\index{Specification!Approaches!Top-Down} -Specifying tests by hand is certainly a professional way of -creating tests; it makes you develop ideas about which parts of a test can -be reused, and also allows test specification to begin before components-have been developed. However, allowing the program to observe user actions -can have its advantages.+As explained in the introduction \bxpref{IntroRecording} and in the section on how to record \bxpref{TasksObsModeTips}, we believe that recording tests has various disadvantages in any tool. -\app{} lets you observe \gdcases{} in a running \gdaut{}, using a method which differs considerably from traditional recording options. You can record actions and checks in your \gdaut{}, but the output for these actions is \gdsteps{}, not code. +However, you can use \app{} to observe \gdcases{} in a running Java \gdaut{}. You can record actions and checks in your \gdaut{}, and the output for these actions is \gdsteps{}. -You can create the same tests with observing as you can with specification. The only real differences are:+You can create the same tests with observing as you can with specification. The real differences are: \begin{itemize} \item object mapping is carried out automatically in observing mode. Because of this, you do not provide a component name, but one is created by \app{}. -\item you must use concrete values for parameters in the observation mode. You can, however, change these to references in the specification perspective later so that your tests are more reusable. +\item you must use concrete values for parameters in the observation mode. You can (and should), however, change these to references in the specification perspective later so that your tests are more reusable. \end{itemize} You can reuse observed \gdcases{} in the same ways as you can reuse specified \gdcases{}. @@ -31,8 +25,7 @@ You can reuse observed \gdcases{} in the same ways as you can reuse specified \g exactly how an action works, look up the component and its action in \bxextref{\gdrefman}{ref,actparam}}. -To execute an observed test, you just need to nest the observed-\gdcase in a \gdsuite{}. This is an example of a top-down approach to testing.+ diff --git a/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Testlogic/teststep.tex b/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Testlogic/teststep.texindex 0cb4c555a..9d4d5e30a 100644--- a/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Testlogic/teststep.tex+++ b/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Testlogic/teststep.tex@@ -12,8 +12,6 @@ \index{Parameter} \index{Action} \index{CAP}-%\index{References}-%\index{Functions} \label{teststeps} A \gdstep{} is the smallest unit in the test hierarchy. Each \gdstep{} represents one action on one component (or user-interface element) in the \gdaut{}. diff --git a/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Working/CONTENT.tex b/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Working/CONTENT.texindex 458bb489a..85392bb80 100644--- a/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Working/CONTENT.tex+++ b/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Working/CONTENT.tex@@ -8,12 +8,12 @@ % copyright by BREDEX GmbH 2004 % -------------------------------------------------------- - %\label{eclipseplugin}+ \app{} is based on the \bxname{Eclipse} development platform, a platform-independent, open-source framework for developing applications. -With the \jbclient{}, you can specify, modify, execute and analyse tests. -The user interface offers various ways of working with \app{}, so that you can choose the way that suits you best. You can alter the way the client looks, and the way it behaves. You can work using the menu bar, the tool bar, context-sensitive menus and shortcuts \bxextref{\gdrefman}{ref,scut}. +With the \ite{}, you can specify, modify, execute and analyse tests. +The user interface offers various ways of working with \app{}, so that you can choose the way that suits you best. You can alter the way the client looks, and the way it behaves. You can work using the menu bar, the tool bar, context-sensitive menus and shortcuts. The important thing to remember is that \app{} lets you work the way \emph{you} want to. diff --git a/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Working/bxenvironments.tex b/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Working/bxenvironments.texdeleted file mode 100644index e66ad51bc..000000000--- a/org.eclipse.jubula.documentation/manual/en/tex/Concepts/Working/bxenvironments.tex+++ /dev/null@@ -1,27 +0,0 @@-% $Id: bxenvironments.tex 1720 2006-03-02 12:25:33Z dennis$-% Local Variables:-% ispell-check-comments: nil-% Local IspellDict: american-% End:-% ---------------------------------------------------------% User documentation-% copyright by BREDEX GmbH 2004-% ----------------------------------------------------------%% \newsavebox{\alex}-%% \newenvironment{bxhint}{%-%% \begin{minipage}{0.8\textwidth}-%% \begin{quote}\itshape}%-%% {\end{quote}\end{minipage}%----\newsavebox{\alex}%-\newenvironment{bxhint}{ -\begin{lrbox}{\alex}-\begin{minipage}{0.1\textwidth}\huge{!}\end{minipage}-\begin{minipage}{0,7\textwidth}-\begin{quote}{\bf Hint:} \\ \end{quote}-\end{minipage}\begin{minipage}{0.1\textwidth}\huge{!}\end{minipage}}-\end{lrbox}-\fbox{\usebox{\alex}}diff --git a/org.eclipse.jubula.documentation/manual/en/tex/Introduction/Intro/approaches.tex b/org.eclipse.jubula.documentation/manual/en/tex/Introduction/Intro/approaches.texindex 386e03650..3c7932e4f 100644--- a/org.eclipse.jubula.documentation/manual/en/tex/Introduction/Intro/approaches.tex+++ b/org.eclipse.jubula.documentation/manual/en/tex/Introduction/Intro/approaches.tex@@ -25,7 +25,7 @@ Tests written in code also have the problem that they no longer view the softwar \subsection{Recorded Tests}-+\label{IntroRecording} Possibly the most popular approach to automated functional testing is macro recording, that is, recording a user's actions for later playback. The appeal of this approach is the apparently quick success that can be seen: a test script can be quickly recorded and played back, giving the impression that automated testing is nothing more than recording a manual test. diff --git a/org.eclipse.jubula.documentation/manual/en/tex/Samples/Adder/eventhandlers.tex b/org.eclipse.jubula.documentation/manual/en/tex/Samples/Adder/eventhandlers.texindex 7a1693225..8ed7271dd 100644--- a/org.eclipse.jubula.documentation/manual/en/tex/Samples/Adder/eventhandlers.tex+++ b/org.eclipse.jubula.documentation/manual/en/tex/Samples/Adder/eventhandlers.tex@@ -25,4 +25,3 @@ The \gdehandler{} in this test has the reentry property \bxname{pause}. When the The \gdehandler{} in this test is different to the \gdehandler{} in the other tests. It contains the same steps as the test itself, but the parameter references have been switched. This essentially changes the order in which the numbers are entered into the Simple Adder. The \gdehandler{} has the reentry property \bxname{retry}. When the error occurs, the \gdehandler{} is activated. The calculation is redone with the switched values. The failed \gdstep{} (i.e. the original check) is retried, and there is no error. The test is marked as successful. \\ -%\bxtipp{Start the \bxname{Simple Adder: local configuration} \gdaut{} to run this test locally. }diff --git a/org.eclipse.jubula.documentation/manual/en/tex/Samples/Adder/library.tex b/org.eclipse.jubula.documentation/manual/en/tex/Samples/Adder/library.texindex 1e8a9800b..fca2634b3 100644--- a/org.eclipse.jubula.documentation/manual/en/tex/Samples/Adder/library.tex+++ b/org.eclipse.jubula.documentation/manual/en/tex/Samples/Adder/library.tex@@ -8,7 +8,7 @@ % copyright by BREDEX GmbH 2004 % -------------------------------------------------------- -This category contains one \gdcase{}. The \gdcase{} contains another \gdcase{}, with four reused \gdcases, which have been reused from the \gdproject{} \bxname{unbound\_modules\_concrete}. +This category contains one \gdcase{}. The \gdcase{} has referenced another \gdcase{}, with four reused \gdcases, which have been reused from the \gdproject{} \bxname{unbound\_modules\_concrete}. \bxtipp{Press \bxkey{F6} to find where a particular \gdcase{} was originally specified. } The \gdcases{} carry out the same steps as in the previous example \bxpref{samplesteststeps}. The differences here are:\\@@ -20,6 +20,6 @@ The \gdcases{} carry out the same steps as in the previous example \bxpref{sampl This \gdcase{} is reused in the executable \gdcase{} \bxname{1.2\_SIMPLE\_ADDER\_TEST}, which is nested in the \gdsuite{} of the same name. -%\bxtipp{Start the \bxname{Simple Adder: local configuration} \gdaut{} to run this test locally. }+ diff --git a/org.eclipse.jubula.documentation/manual/en/tex/Samples/Adder/teststeps.tex b/org.eclipse.jubula.documentation/manual/en/tex/Samples/Adder/teststeps.texindex f9b8c52ea..a3aed8582 100644--- a/org.eclipse.jubula.documentation/manual/en/tex/Samples/Adder/teststeps.tex+++ b/org.eclipse.jubula.documentation/manual/en/tex/Samples/Adder/teststeps.tex@@ -10,5 +10,4 @@ This category contains one \gdcase{}. The \gdcase{} contains four \gdsteps{}, which test an addition in the Simple Adder. The parameter values in the \gdsteps{} have been referenced, and a data set has been added. -This is an example of a top-down test \bxpref{topdownconcepts}. This may be preferred in some circumstances, but \app{}'s power lies in the reusability options it offers, as shown in the following examples. -+This is an example of a test written with \gdsteps{}. However, we recommend using the library of \gdcases{} to write tests, as shown in the next examples. diff --git a/org.eclipse.jubula.documentation/manual/en/tex/Samples/Intro/accessing.tex b/org.eclipse.jubula.documentation/manual/en/tex/Samples/Intro/accessing.texindex becf63525..92f75b383 100644--- a/org.eclipse.jubula.documentation/manual/en/tex/Samples/Intro/accessing.tex+++ b/org.eclipse.jubula.documentation/manual/en/tex/Samples/Intro/accessing.tex@@ -11,9 +11,9 @@ You can find the \gdproject{} containing the tests in the \app{} installation directory under the subdirectory:\\ \bxname{examples/projects}. -You can import the \gdproject{} into the \app{}-client as follows:+You can import the \gdproject{} into the \ite{} as follows: \begin{enumerate}-\item Select:\\ \bxmenu{Project}{Import}{}.+\item Select:\\ \bxmenu{Test}{Import}{}. \item Browse to the \bxname{examples/projects} directory in the \app{} installation directory. \item Select both the \bxname{samples} \gdproject{} and the \bxname{bound\_modules\_samples} \gdproject{}. \item Select \bxcaption{OK} in the \bxname{Import Project} dialog. @@ -26,14 +26,10 @@ Once a \gdprojects have been imported, open the \bxname{samples} \gdproject{}. S When working on one machine, it may be a good idea to automatically minimize \app{}during test execution. This can be done via :\\ \bxmenu{Window}{Preferences}{}. \\+In the \bxname{Test} preferences. Alternatively, the client window can be reduced so that both the client and the \gdaut{} can be seen. \subsubsection{Result Reports} A result report of the test will be automatically saved into the \gddb{} when the test has run. The summary of the reports can be viewed in the \gdtestsummaryview{} \bxpref{testresultview}.---You can also choose to generate result reports for test execution. --The HTML and XML reports can then be seen in the directory defined when this option is selected. diff --git a/org.eclipse.jubula.documentation/manual/en/tex/Samples/Meters/CONTENT.tex b/org.eclipse.jubula.documentation/manual/en/tex/Samples/Meters/CONTENT.texindex 4baae3665..e65aed462 100644--- a/org.eclipse.jubula.documentation/manual/en/tex/Samples/Meters/CONTENT.tex+++ b/org.eclipse.jubula.documentation/manual/en/tex/Samples/Meters/CONTENT.tex@@ -2,24 +2,26 @@ The meters application is a piece of software designed to manage meter readings The most basic use case for this application is to take a meter reading. Taking a meter reading is also a part of the other two use cases shown in this example, moving a tenant in and moving a tenant out of the complex. -The Excel files needed for this \gdproject{} can be found in: \\-\bxname{/examples/Samples.zip}\\-You will need to take the following steps to be able to run the meters tests:-\begin{enumerate}-\item Open the \app{} Workspace Perspective:\\-\bxmenu{Window}{Open Perspective}{\app{}Workspace}-\item Right-click in the \gdnavview{} and select:\\-\bxmenu{Import}{}{}\\-from the context-sensitive menu. -\item In the dialog that appears, select \bxname{Existing Projects into Workspace} from the \bxname{General} category. -\item Press \bxcaption{Next}.-\item In the next dialog, activate the \bxname{Select archive file} option.-\item Browse to the \app{} installation directory and then to the-\bxname{examples} directory. -\item Select the \bxname{Samples.zip}. -\item Click \bxcaption{Finish} in the dialog. The Excel files for the meters tests will appear in the \gdnavview{}. -\item If you do not have write privileges in the \app{} installation directory, you must also create a workspace for the meters application and enter this workspace in the \gdaut{} configuration for meters. In the \bxname{AUT Arguments} field, enter: \bxshell{-data }.-\end{enumerate}+This test uses central test data sets to manage its data \bxpref{TasksCentralData}. ++%% The Excel files needed for this \gdproject{} can be found in: \\+%% \bxname{/examples/Samples.zip}\\+%% You will need to take the following steps to be able to run the meters tests:+%% \begin{enumerate}+%% \item Open the \app{} Workspace Perspective:\\+%% \bxmenu{Window}{Open Perspective}{\app{}Workspace}+%% \item Right-click in the \gdnavview{} and select:\\+%% \bxmenu{Import}{}{}\\+%% from the context-sensitive menu. +%% \item In the dialog that appears, select \bxname{Existing Projects into Workspace} from the \bxname{General} category. +%% \item Press \bxcaption{Next}.+%% \item In the next dialog, activate the \bxname{Select archive file} option.+%% \item Browse to the \app{} installation directory and then to the+%% \bxname{examples} directory. +%% \item Select the \bxname{Samples.zip}. +%% \item Click \bxcaption{Finish} in the dialog. The Excel files for the meters tests will appear in the \gdnavview{}. +%% \item If you do not have write privileges in the \app{} installation directory, you must also create a workspace for the meters application and enter this workspace in the \gdaut{} configuration for meters. In the \bxname{AUT Arguments} field, enter: \bxshell{-data }.+%% \end{enumerate} \subsection{Sample 5: Tests with the Meters tool}diff --git a/org.eclipse.jubula.documentation/manual/en/tex/Samples/Meters/test.tex b/org.eclipse.jubula.documentation/manual/en/tex/Samples/Meters/test.texindex 0db7d2a40..6900f1520 100644--- a/org.eclipse.jubula.documentation/manual/en/tex/Samples/Meters/test.tex+++ b/org.eclipse.jubula.documentation/manual/en/tex/Samples/Meters/test.tex@@ -9,9 +9,5 @@ The test for the meters tool contains three use cases. In the \bxname{bound\_modules\_samples} \gdproject{}, you can see the building blocks that these use cases are made up of in the \bxname{AUT bound modules} category. -\subsubsection{Excel files}-The meters tests use Excel files to provide most of the data they need. In the Excel files, you can see that the test can run in German and English. Change the working language before starting the \gdaut{} to start the \gdaut{} and run the test in a different language. -- \subsubsection{Concatenated parameters} The meters application has a fairly complex tree structure in terms of the data in it. Look in the \gdcase{} \bxname{mtr\_tre\_selectNode} in the \bxname{bound\_modules\_samples} \gdproject{} to see how the treepath has been concatenated out of the concrete value \bxname{Building} and then two further parameters for the location of the meter and the meter number. This makes entering the test data easier. diff --git a/org.eclipse.jubula.documentation/manual/en/tex/Tasks/Browsers/intro.tex b/org.eclipse.jubula.documentation/manual/en/tex/Tasks/Browsers/intro.texindex d0ed5d110..9e5825fca 100644--- a/org.eclipse.jubula.documentation/manual/en/tex/Tasks/Browsers/intro.tex+++ b/org.eclipse.jubula.documentation/manual/en/tex/Tasks/Browsers/intro.tex@@ -1 +1,5 @@+Select an item in a browser to see read-only details in the \gdpropview{}, \gddatasetsview{} and \gdcompnamesview{} for this item. + You can rename items from the \gdtestcasebrowser{}, \gdtestsuitebrowser{} or \gdcompnamebrowser{}. ++You can open editors for items in certain browsers. See the later section \bxpref{WorkingWithEditors} for more details.diff --git a/org.eclipse.jubula.documentation/manual/en/tex/Tasks/Commandline/configfile.tex b/org.eclipse.jubula.documentation/manual/en/tex/Tasks/Commandline/configfile.texindex 763044171..320af2637 100644--- a/org.eclipse.jubula.documentation/manual/en/tex/Tasks/Commandline/configfile.tex+++ b/org.eclipse.jubula.documentation/manual/en/tex/Tasks/Commandline/configfile.tex@@ -38,8 +38,8 @@ For example: local configuration OR Adder- Embedded- + embedded+ sa localhost 60000diff --git a/org.eclipse.jubula.documentation/manual/en/tex/Tasks/Commandline/embedded.tex b/org.eclipse.jubula.documentation/manual/en/tex/Tasks/Commandline/embedded.texindex cc7a81ff2..13a7668d2 100644--- a/org.eclipse.jubula.documentation/manual/en/tex/Tasks/Commandline/embedded.tex+++ b/org.eclipse.jubula.documentation/manual/en/tex/Tasks/Commandline/embedded.tex@@ -2,9 +2,9 @@ If you are using the default embedded \gddb{}, you will need to enter the following information as parameters: \begin{description}-\item[-dbscheme]{Embedded}-\item[-dbuser]{}-\item[-dbpw]{}+\item[-dbscheme]{embedded}+\item[-dbuser]{sa}+\item[-dbpw]{ (\bxshell{''''})} \end{description}-If you have changed the name of the default \gddb{} scheme in the configuration tool, you should alter the parameter for the \bxname{-dbscheme} accordingly. +If you have changed the name of the default \gddb{} scheme in the \gddb{} preferences \bxpref{TasksPrefsDB}, you should alter the parameter for the \bxname{-dbscheme} accordingly. diff --git a/org.eclipse.jubula.documentation/manual/en/tex/Tasks/Commandline/parameters.tex b/org.eclipse.jubula.documentation/manual/en/tex/Tasks/Commandline/parameters.texindex ec4b82b0d..78c112ead 100644--- a/org.eclipse.jubula.documentation/manual/en/tex/Tasks/Commandline/parameters.tex+++ b/org.eclipse.jubula.documentation/manual/en/tex/Tasks/Commandline/parameters.tex@@ -41,10 +41,12 @@ \gdaut{} configuration name & \bxshell{-autconfig }\\ &e.g. \emph{-autconfig ''localconfiguration''}\\+ &Use when starting an \gdaut{} via a configuration.\\ \hline \gdaut{} ID & \bxshell{-autid }\\ &e.g. \emph{-autid ''SimpleAdder1''}\\+ &Use when \gdaut{} was started via \bxname{autrun}.\\ \hline Configuration file & \bxshell{-c }\\@@ -77,10 +79,12 @@ Test Suite & \bxshell{-testsuite }\\ &e.g. \emph{-testsuite ''suite1''}\\+ &Use to start a \gdsuite{}\\ \hline Test Job & \bxshell{-testjob }\\ &e.g. \emph{-testjob ''job1''}\\+ &Use to start a \gdjob{}\\ \hline Workspace & \bxshell{-data }\\diff --git a/org.eclipse.jubula.documentation/manual/en/tex/Tasks/DBTool/CONTENT.tex b/org.eclipse.jubula.documentation/manual/en/tex/Tasks/DBTool/CONTENT.texindex 100820cb3..49e90721d 100644--- a/org.eclipse.jubula.documentation/manual/en/tex/Tasks/DBTool/CONTENT.tex+++ b/org.eclipse.jubula.documentation/manual/en/tex/Tasks/DBTool/CONTENT.tex@@ -1,7 +1,7 @@ \input{Tasks/DBTool/intro} -\subsection{Starting the GUIdancerDBTool}+\subsection{Starting the dbtool} \input{Tasks/DBTool/starting} -\subsection{Parameters for the GUIdancerDBTool}+\subsection{Parameters for the dbtool} \input{Tasks/DBTool/parameters}diff --git a/org.eclipse.jubula.documentation/manual/en/tex/Tasks/DBTool/intro.tex b/org.eclipse.jubula.documentation/manual/en/tex/Tasks/DBTool/intro.texindex f8f0c70f5..498082c06 100644--- a/org.eclipse.jubula.documentation/manual/en/tex/Tasks/DBTool/intro.tex+++ b/org.eclipse.jubula.documentation/manual/en/tex/Tasks/DBTool/intro.tex@@ -1,3 +1,3 @@-You can use the \app{} \gddb{} tool (GUIdancerDBTool) to import, export and delete \gdprojects{} from the \gddb{} in \app{} without using the \app{} client. +You can use the dbtool to import, export and delete \gdprojects{} from the \gddb{} in without using the \ite{}. This is particularly useful for automated build and test processes, where you may want to automatically export and import \gdprojects{} out of and into version control to run your tests. diff --git a/org.eclipse.jubula.documentation/manual/en/tex/Tasks/DBTool/parameters.tex b/org.eclipse.jubula.documentation/manual/en/tex/Tasks/DBTool/parameters.texindex 1bb2002cb..14b44d915 100644--- a/org.eclipse.jubula.documentation/manual/en/tex/Tasks/DBTool/parameters.tex+++ b/org.eclipse.jubula.documentation/manual/en/tex/Tasks/DBTool/parameters.tex@@ -1,7 +1,7 @@-\index{DB Tool}+\index{dbtool} \begin{enumerate}-\item Once you have browsed to the \app{} installation directory and entered \bxshell{GUIdancerDBTool}, you can enter the parameters for the \gddb{} actions.-\item The DBTool uses the parameters described in the table \bxfigref{dbtoolparams}:+\item Once you have browsed to the \app{} installation directory and entered \bxshell{dbtool}, you can enter the parameters for the \gddb{} actions.+\item The dbtool uses the parameters described in the table \bxfigref{dbtoolparams}: \begin{table}[h]@@ -63,7 +63,7 @@ &If no URL is given, the default will be used.\\ \hline \end{tabular}- \caption{Parameters for the DBTool}+ \caption{Parameters for the dbtool} \end{table} \item You can use the parameter \bxshell{-keepsummary} to specify that the test result summaries should not be deleted when the \gdproject{} or \gdprojects{} are deleted. This is useful for continuous integration processes, where the test results over time should be kept, but the \gdprojects{} are reimported into the \gddb{} (for example from the version control system) each night. If you do not enter this parameter, the summaries will be deleted with the \gdprojects{}.diff --git a/org.eclipse.jubula.documentation/manual/en/tex/Tasks/DBTool/starting.tex b/org.eclipse.jubula.documentation/manual/en/tex/Tasks/DBTool/starting.texindex e3aae4e8b..7e563f72e 100644--- a/org.eclipse.jubula.documentation/manual/en/tex/Tasks/DBTool/starting.tex+++ b/org.eclipse.jubula.documentation/manual/en/tex/Tasks/DBTool/starting.tex@@ -1,10 +1,10 @@ -\index{DB Tool}+\index{dbtool} \begin{enumerate} \item In a command line interface, locate the \app{} installation directory and open the \app{} directory within it. -\item Enter \bxshell{GUIdancerDBTool.exe}. +\item Enter \bxshell{dbtool.exe}. -This will run the executable \emph{GUIdancerDBTool.exe}.+This will run the executable \emph{dbtool.exe}. \item Do not press \bxkey{enter} until you have entered the necessary parameters. See the next section for details on the parameters. \end{enumerate} diff --git a/org.eclipse.jubula.documentation/manual/en/tex/Tasks/SECTIONS.tex b/org.eclipse.jubula.documentation/manual/en/tex/Tasks/SECTIONS.texindex 02dbb961a..cf0fcd613 100644--- a/org.eclipse.jubula.documentation/manual/en/tex/Tasks/SECTIONS.tex+++ b/org.eclipse.jubula.documentation/manual/en/tex/Tasks/SECTIONS.tex@@ -114,6 +114,7 @@ For more details about individual tasks, read the \bxref{Concepts} \clearpage \section{Test execution}+\label{TestExec} \input{Tasks/Testexecution/CONTENT} \clearpagediff --git a/org.eclipse.jubula.documentation/manual/en/tex/Tasks/Testresults/summary.tex b/org.eclipse.jubula.documentation/manual/en/tex/Tasks/Testresults/summary.texindex 602d71900..e18702402 100644--- a/org.eclipse.jubula.documentation/manual/en/tex/Tasks/Testresults/summary.tex+++ b/org.eclipse.jubula.documentation/manual/en/tex/Tasks/Testresults/summary.tex@@ -3,6 +3,7 @@ You can see the test result summaries in the \reportpersp{}, in the \gdtestsummaryview{}. \subsubsection{Re-opening the test result view for a test run}+\gdhelpid{testResultSummaryViewContextId}{Test Result Summary View} \label{TasksReopenTestResult} \begin{enumerate} \item If the full details for a test run are still available (the column \bxname{Details} shows \bxname{true}), you can re-open the full test result by double-clicking on the entry in the \gdtestsummaryview{} or by clicking the button to open the report in the top right-hand corner of the view. diff --git a/org.eclipse.jubula.documentation/manual/en/tex/Userinterface/Editors/browsers.tex b/org.eclipse.jubula.documentation/manual/en/tex/Userinterface/Editors/browsers.texindex 8822fde33..81dc6aa3b 100644--- a/org.eclipse.jubula.documentation/manual/en/tex/Userinterface/Editors/browsers.tex+++ b/org.eclipse.jubula.documentation/manual/en/tex/Userinterface/Editors/browsers.tex@@ -12,32 +12,32 @@ There are three browsers in \app{}: \begin{description}-\item[The \gdtestcasebrowser{}]{ lets you create and see your \gdcases{}. }-\item[The \gdtestsuitebrowser{}]{ lets you create and see your \gdsuites{}.}+\item[The \gdtestcasebrowser{}]{ lets you create and manage your \gdcases{}. }+\item[The \gdtestsuitebrowser{}]{ lets you create and manage your \gdsuites{}.} \item [The \gdcompnamebrowser{}]{lets you see, merge add and delete component names.} \end{description} \subsection{The \gdtestsuitebrowser{}} \gdhelpid{testExecutionViewContextId}{Test Suite Browser}-The \gdtestsuitebrowser{} is by default in the upper left-hand corner of the specification perspective. In this browser, you can create \gdsuites{}, which are used to collect and execute \gdcases{}. +The \gdtestsuitebrowser{} is by default in the upper left-hand corner of the \specpersp{}. In this browser, you can create \gdsuites{} and \gdjobs{} for executing tests. ++More information on working with browsers is available in the Tasks chapter \bxpref{WorkingWithBrowsers}. -If you double-click on a \gdsuite{} in this browser, the \gdtestsuiteeditor{} will open. -If you single-click on a \gdsuite{} in this browser, you can see read-only details for it in the \gdpropview{}, the \gddatasetsview{} and the \gdcompnamesview{}. \bxtipp{You can filter in the \gdtestsuitebrowser{} using the field at the top. Use star \bxshell{*} as a wild card.} \subsection{The \gdtestcasebrowser{}} \gdhelpid{testSpecificationViewContextId}{Test Case Browser} -The \gdtestcasebrowser{} is by default in the lower left-hand corner of the specification perspective. In this browser, you can create \gdcases{}, which are the ''building blocks'' in \app{}. They are used to group \gdsteps{} and other \gdcases{}. +The \gdtestcasebrowser{} is by default in the lower left-hand corner of the \specpersp{}. In this browser, you can create \gdcases{}, which are the ''building blocks'' in \app{}. They are used to group \gdsteps{} and other \gdcases{}. ++More information on working with browsers is available in the Tasks chapter \bxpref{WorkingWithBrowsers}. -If you double-click on a \gdcase{} in this browser, the \gdtestcaseeditor{} will open. -If you single-click on a \gdcase{} in this browser, you can see read-only details for it in the \gdpropview{}, the \gddatasetsview{} and the \gdcompnamesview{}. \bxtipp{You can filter in the \gdtestcasebrowser{} using the field at the top. Use star \bxshell{*} as a wild card.} \subsection{The \gdcompnamebrowser} \gdhelpid{guidancerComponentNameBrowserContextId}{Component Name Browser} -The \gdcompnamebrowser{} (\bxfigref{compnamesbrowser}) is by default in the lower left-hand corner of the specification perspective, begind the \gdtestcasebrowser{}. In this browser, you can see component names used in this \gdproject{} and in other \gdprojects{}. You can rename, add, delete and merge component names and can also find where you have used component names in your test. +The \gdcompnamebrowser{} (\bxfigref{compnamesbrowser}) is by default in the lower left-hand corner of the \specpersp{}, behind the \gdtestcasebrowser{}. In this browser, you can see component names used in this \gdproject{} and in other \gdprojects{}. You can rename, add, delete and merge component names and can also find where you have used component names in your test. \bxtipp{You can filter in the \gdcompnamebrowser{} using the field at the top. Use star \bxshell{*} as a wild card.} diff --git a/org.eclipse.jubula.documentation/manual/en/tex/Userinterface/Editors/editors.tex b/org.eclipse.jubula.documentation/manual/en/tex/Userinterface/Editors/editors.texindex 83ea5d036..38317ac19 100644--- a/org.eclipse.jubula.documentation/manual/en/tex/Userinterface/Editors/editors.tex+++ b/org.eclipse.jubula.documentation/manual/en/tex/Userinterface/Editors/editors.tex@@ -7,7 +7,7 @@ % User documentation % copyright by BREDEX GmbH 2004 % -------------------------------------------------------- -Editors appear in the editor area in the middle of the specification perspective when you double-click \gdcase{}, \gdsuite{} or \gdcase{} model in one of the browsers or in the \gdnavview{}. +Editors appear in the editor area in the middle of the perspective when you double-click an item in one of the browsers or in the \gdnavview{}. You can tell what sort of editor it is in two ways: \begin{enumerate} @@ -17,21 +17,19 @@ You can tell what sort of editor it is in two ways: \item \bxcaption{TS} for the \gdtestsuiteeditor{} \item \bxcaption{OM} for the \gdomeditor{} \item \bxcaption{TD} for the \gddataeditor{} -\item The \gdmodeleditor shows the model diagram name with \bxname{.gtm} after it. \end{itemize} -The tab also shows the name of the \gdcase{}, \gdsuite{}, \gdaut{}, data set or model diagram the editor is for. -%\item The borders of the editor are colored according to the type of editor. By default, the \gdtestcaseeditor{} has brown borders and the \gdtestsuiteeditor{} has blue borders. +The tab also shows the name of the item the editor is for. + \end{enumerate} -%picture + \subsection{\gdtestcaseeditor{}} \gdhelpid{guidancerSpecTestCaseEditorContextId}{Test Case Editor} \index{Test Case!Editor} \index{Editor!Test Case} -You can open the \gdtestcaseeditor{} by double-clicking on a \gdcase{} in the \gdtestcasebrowser{}. -Each \gdtestcaseeditor{} displays the name of the \gdcase{} in its tab along with the ID-code \bxcaption{TC}. The borders of the \gdtestcaseeditor{} are brown by default. +You can open the \gdtestcaseeditor{} by double-clicking a \gdcase{} in the \gdtestcasebrowser{}. In the \gdtestcaseeditor{}: \begin{itemize} @@ -41,14 +39,15 @@ In the \gdtestcaseeditor{}: \item You can alter test data and component names for the \gdcase{}. \end{itemize} -When you single-click items (\gdcases{}, \gdsteps{}) in the \gdtestcaseeditor{}, the support views (\gdpropview{}, \gdcompnamesview{} and \gddatasetsview{}) show details about this item. Using these views, you can edit the properties, test data and component names for this item. You can also add or overwrite comments for the item. +When you single-click items (\gdcases{}, \gdsteps{}) in the \gdtestcaseeditor{}, the support views (\gdpropview{}, \gdcompnamesview{} and \gddatasetsview{}) show details about this item. Using these views, you can edit the properties, test data and component names for this item. \subsection{\gdtestsuiteeditor} \gdhelpid{testSuiteEditorContextId}{Test Suite Editor} \index{Test Suite!Editor} \index{Editor!Test Suite} -You can open the \gdtestsuiteeditor{} by double-clicking on a \gdsuite{} in the \gdtestsuitebrowser{}. -Each \gdtestsuiteeditor{} displays the name of the \gdsuite{} in its tab along with the ID-code \bxcaption{TS}. The borders of the \gdtestsuiteeditor{} are blue by default. + +You can open the \gdtestsuiteeditor{} by double-clicking a \gdsuite{} in the \gdtestsuitebrowser{}. + In the \gdtestsuiteeditor{}: \begin{itemize} @@ -60,19 +59,17 @@ In the \gdtestsuiteeditor{}: \bxtipp{In the \gdtestsuiteeditor{}, you can only alter details for the top-level \gdcases{} for each subtree.} - When you single-click \gdcases{} in the \gdtestsuiteeditor{}, the support views (\gdpropview{}, \gdcompnamesview{} and \gddatasetsview{}) show details about this \gdcase{}. Using these views, you can edit the properties, test data and component names for this item. You can also add or overwrite comments for the item. + When you single-click \gdcases{} in the \gdtestsuiteeditor{}, the support views (\gdpropview{}, \gdcompnamesview{} and \gddatasetsview{}) show details about this \gdcase{}. Using these views, you can edit the properties, test data and component names for this item. \subsection{\gdomeditor} \gdhelpid{objectMapEditorContextId}{Object Mapping} \index{Object Mapping!Editor} \index{Editor!Object Mapping} -You can open the \gdomeditor{} by right-clicking on a \gdsuite{} in the \gdtestsuitebrowser{} and selecting \bxcaption{open with \gdomeditor{}}. +Each \gdaut{} in a \gdproject{} has an \gdomeditor{}. You can open the \gdomeditor{} by right-clicking on a \gdsuite{} in the \gdtestsuitebrowser{} and selecting \bxcaption{open with \gdomeditor{}}. You can also open the \gdomeditor{} by single-clicking the chosen \gdsuite{} and clicking on the \bxcaption{start \gdomm{}} button on the toolbar. This also starts the \gdomm{}. -Each \gdaut{} has a \gdomeditor{}. The \gdomeditor{} displays the ID-code \bxcaption{OM} in its tab, and the name of the \gdaut{} it is used for. - The \gdomeditor{} has four tabs, a split view, a tree view, a table view and configuration tab. In the \gdomeditor{}: \begin{itemize} @@ -96,16 +93,3 @@ In the \gddataeditor{}: \end{itemize} -\subsection{\gdmodeleditor{}} -\gdhelpid{guidancerModelEditorContextId}{Modeling Editor} - -You can open the \gdmodeleditor{} by double-clicking on a model diagram in the \gdnavview{}. -Each \gdmodeleditor{} displays the name of the model in its tab. - -In the \gdmodeleditor{}: -\begin{itemize} -\item You can add and edit \gdcases{}, categories, referenced \gdcases{} and parameters to the model. -\item You can validate your model. -\item You can generate your model. -\end{itemize} - diff --git a/org.eclipse.jubula.documentation/manual/en/tex/Userinterface/Editors/intro.tex b/org.eclipse.jubula.documentation/manual/en/tex/Userinterface/Editors/intro.texindex 648b14e90..6cb25712d 100644--- a/org.eclipse.jubula.documentation/manual/en/tex/Userinterface/Editors/intro.tex+++ b/org.eclipse.jubula.documentation/manual/en/tex/Userinterface/Editors/intro.tex@@ -17,7 +17,7 @@ There are four types of area in the \app{} user interface: \textbf{Perspectives} -There are three perspectives, specification, execution and modeling, each with a different function. A perspective is a collection of views, editors and browsers on the screen. +A perspective is a collection of views, editors and browsers on the screen. \textbf{Browsers} @@ -25,8 +25,7 @@ Browsers let you see the \gdcases{} and \gdsuites{} you have created in their hi \textbf{Editors} -Editors let you modify, add and delete items in \gdcases{} and \gdsuites{}. You can open editors by double-clicking on a node (e.g. \gdsuite{} or \gdcase{}) in a browser. In the modeling perspective, the editor is the canvas for your models. -+Editors let you modify, add and delete items. You can open editors by double-clicking on a node (e.g. \gdsuite{} or \gdcase{}) in a browser. \textbf{Views} @@ -39,25 +38,5 @@ You can change the way your user interface looks by moving areas, changing the c To reset the default layout at any time, select:\\ \bxmenu{Window}{Reset Perspective}{}. -%% \subsection{Color coding}-%% Because \app{} contains user interface elements whose contents change depending on what is selected, we use a color coding system to distinguish between areas used for specification and execution. --%% The areas used for specification have brown borders by default. These are:-%% \begin{itemize}-%% \item The \gdtestcasebrowser{}-%% \item The \gdtestcaseeditor{}-%% \item The \gdpropview{}, \gdcompnamesview{} and \gddatasetsview{} when they are showing details about an item selected in one of the two areas above. -%% \end{itemize}--%% The areas used for execution have blue borders by default. These are:-%% \begin{itemize}-%% \item The \gdtestsuitebrowser{}-%% \item The \gdtestsuiteeditor{}-%% \item The \gdtestresultview{}-%% \item The \gdpropview{}, \gdcompnamesview{} and \gddatasetsview{} when they are showing details about an item selected in one of the three areas above.-%% \end{itemize}--%% You can change the colors or switch the color coding off in the \bxcaption{appearance} preferences. - diff --git a/org.eclipse.jubula.documentation/manual/en/tex/Userinterface/Editors/perspectives.tex b/org.eclipse.jubula.documentation/manual/en/tex/Userinterface/Editors/perspectives.texindex deeb7aa84..0c1a95342 100644--- a/org.eclipse.jubula.documentation/manual/en/tex/Userinterface/Editors/perspectives.tex+++ b/org.eclipse.jubula.documentation/manual/en/tex/Userinterface/Editors/perspectives.tex@@ -7,26 +7,7 @@ % User documentation % copyright by BREDEX GmbH 2004 % ---------------------------------------------------------\index{Perspective!Execution}-\index{Execution!Perspective}-\index{View!Test Result}-\index{Test Result!View}--There are five perspectives in \app{}: -\begin{itemize}-\item Specification-\gdmarpar{../../../share/PS/perspectivesp}{specification}- \item Execution-\gdmarpar{../../../share/PS/perspectiveex}{execution}-\item Modeling-%\gdmarpar{../../../share/PS/perspectiveex}{execution}-\item Workspace-\item Reporting--\end{itemize} ---\subsection{The specification perspective}+\subsection{The \specpersp{}} \index{Specification!Perspective} \index{Perspective!Specification} \index{Browser!Test Suite}@@ -45,7 +26,9 @@ There are five perspectives in \app{}: \index{Problem View} \index{Component!Names!View} \index{View!Component Names}-The specification perspective (\bxfigref{clientwindow}) provides browsers, editors and views to let you create tests. It contains:+The \specpersp{} (\bxfigref{clientwindow}) provides browsers, editors and views to let you create and edit tests.++It contains: \begin{itemize} \item The \gdtestsuitebrowser{} @@ -60,73 +43,68 @@ The specification perspective (\bxfigref{clientwindow}) provides browsers, edito \item The \gdrunautview{} \end{itemize} +The \gdcompnamesview{}, \gddatasetsview{} and \gdpropview{} show you details about the currently selected item in the browser or editor. + \begin{figure} \includegraphics[width=12.5cm]{Userinterface/Editors/PS/client} \caption{\app{} Specification Perspective} \label{clientwindow} \end{figure} -\clearpage -The \gdtestcasebrowser{} and the \gdtestsuitebrowser{} let you see your \gdcases{} and \gdsuites{}. If you double-click an item in one of these browsers, an editor for this item opens. Using the editor and its support views (numbers 4-6) you can edit the contents and properties of \gdsuites{}, \gdcases{} and \gdsteps{}. The content of the support view changes according to the currently selected item. \clearpage-\subsection{The execution perspective}+\subsection{The \execpersp{}} \index{Execution!Perspective} \index{Perspective!Execution} \index{Views!Test Result} \index{Test Result!View} -In the execution perspective, you can see the following (\bxfigref{executionclient}):+In the \execpersp{}, you can see the following (\bxfigref{executionclient}): \begin{itemize}-\item \gdtestsuitebrowser -\item \gdtestresultview -\item \gdpropview -\item \gddatasetsview+\item The \gdtestsuitebrowser{}+\item The \gdtestresultview{}+\item The \gdpropview{} +\item The \gdimgview{} \end{itemize} \begin{figure} \includegraphics{Userinterface/Editors/PS/executionclient}-\caption{\app{} Execution Perspective}+\caption{\execpersp{}} \label{executionclient} \end{figure} -You cannot edit in the execution perspective, but you can see your \gdsuite{} and its results. +You cannot edit in the \execpersp{}, but you can see the results of tests that have been started interactively.. \clearpage -\subsection{The modeling perspective}-\index{Perspective!Modeling}-\index{Modeling!Perspective}-\index{Views!Navigator}-\index{Navigator View}-\index{Outline View}-\index{Views!Outline}-\index{Editor!Test Case Model}-\index{Test Case!Model Editor}+\subsection{The \reportpersp{}}+\index{Reporting!Perspective}+\index{Perspective!Reporting}+\index{Views!Test Result Summary}+\index{Test Result Summary!View} -In the modeling perspective (\bxfigref{modelperspective}), you can create \gdprojects{} in your workspace to create and import model diagrams which can then be generated into a \gdcase{\ structure. The modeling perspective contains the following:+In the \reportpersp{}, you can see an overview of all the test runs in the current \gddb{}, for all \gdprojects{} it contains. You can reopen test runs if the details for the report are still in the \gddb{} \bxpref{TasksReopenTestResult} and analyze the test using the \gdpropview{} and the \gdimgview{}. +The \reportpersp{} (\bxfigref{reportingperspective}) contains the following views: \begin{itemize}-\item \gdnavview{} -\item \gdmodeleditor{}-\item \bxname{Outline View}-\item \gdpropview{}-\item \bxname{Console}-\item \gdtestcasebrowser{}-\item \gdprobview{}+\item The \gdtestresultview{}+\item The \gdpropview{} +\item The \gdimgview{}+\item The \gdtestsummaryview{} \end{itemize} + \begin{figure}-\includegraphics{Userinterface/Editors/PS/modelperspective}-\caption{\app{} Modeling Perspective}-\label{modelperspective}+\includegraphics[width=12.5cm]{Userinterface/Editors/PS/reportingperspective}+\caption{\app{} Reporting Perspective}+\label{reportingperspective} \end{figure}- \clearpage + \subsection{The \app{} workspace perspective} \index{Perspective!Workspace} \index{Workspace!Perspective}@@ -134,7 +112,7 @@ In the modeling perspective (\bxfigref{modelperspective}), you can create \gdpro \index{Navigator View} -In the workspace perspective (\bxfigref{workspaceperspective}), you can view the \gdprojects{} and files in your \app{} workspace. The workspace perspective contains the following:+In the workspace perspective (\bxfigref{workspaceperspective}), you can view the \gdprojects{} and files in your workspace. The workspace perspective contains the following: \begin{itemize}@@ -149,16 +127,4 @@ In the workspace perspective (\bxfigref{workspaceperspective}), you can view the \end{figure} \clearpage -\subsection{The \app{} reporting perspective}-\index{Perspective!Reporting}-\index{Reporting!Perspective}-\index{Views!Test Result Summary}-\index{Test Result Summary View}-In the reporting perspective, the only view is the \gdtestsummaryview{}. You can see an overview of all tests that have run in this \gddb{}. -\begin{figure}-\includegraphics[width=12.5cm]{Userinterface/Editors/PS/reportingperspective}-\caption{\app{} Reporting Perspective}-\label{reportingperspective}-\end{figure}-\clearpagediff --git a/org.eclipse.jubula.documentation/manual/en/tex/Userinterface/Editors/views.tex b/org.eclipse.jubula.documentation/manual/en/tex/Userinterface/Editors/views.texindex d118f1cda..1e7768b7f 100644--- a/org.eclipse.jubula.documentation/manual/en/tex/Userinterface/Editors/views.tex+++ b/org.eclipse.jubula.documentation/manual/en/tex/Userinterface/Editors/views.tex@@ -26,8 +26,6 @@ \index{Navigator View} \index{Console!View} \index{View!Console}-\index{View!Outline}-\index{Outline!View} \index{Test Result Summary View} \index{View!Test Result Summary} \index{View!Running AUT's}@@ -47,7 +45,6 @@ \item \gdprobview{} \item Search result view \item \gdnavview{}-\item Outline view \item Console \item \gdinspector{} \item \gdtestsummaryview{}@@ -57,16 +54,11 @@ The first three views are \emph{support views}. Their content changes depending on the current selection -- they show details corresponding to the currently selected item. +Use \bxmenu{Window}{Show View}{Other} to see a full list of views that can be opened in the \ite{}. \subsection{The \gdpropview{}} \gdhelpid{guidancerPropertiesViewContextId}{Properties View} -The \gdpropview{} is in the upper right-hand corner of each perspective. Depending on the currently selected item, the \gdpropview{} shows details about:-\begin{itemize}- \item \gdsuites{} - \item \gdcase{} details- \item \gdstep{} details- \item Test result details-\end{itemize}+The \gdpropview{} is in the upper right-hand corner of each perspective. The \gdpropview{} shows details about the selected item in a browser or editor. If you select something from a browser, you can see its details in the \gdpropview{}, but you can't edit them. You can only edit details from within an editor. Read-only fields in the \gdpropview{} have a lock icon at their left-hand side. \gdmarpar{../../../share/PS/readonly}{read only}@@ -89,12 +81,10 @@ If you select a \gdcase{}, the \gdpropview{} shows the following: \begin{itemize} \item The \gdcase{} name. \item Any comments for the \gdcase{}. -\item The path to the Excel file for this \gdcase{}, if there is one. -\item Any parameters/parameter values if references have been used to move up parameters in the \gdcase{}. +\item The data source details for this \gdcase{}+\item Any parameters/parameter values if references have been used in the \gdcase{}. \end{itemize} -If you select a \gdcase{} from the \gdtestsuitebrowser{}, you will see the same details as above, but also the \emph{specification name} for the \gdcase{}, if you renamed the \gdcase{} when you reused it. - \textbf{\gdstep{} details} @@ -123,7 +113,7 @@ If you select an item from the \gdtestresultview{}, you will see the following: \item The result details: \begin{itemize} \item The name of the item.-\item What type of item it was (\gdsuite{}, \gdcase{}, \gdstep{}). +\item What type of item it is. \item Any comments for the item. \end{itemize} \item The test result -- if it passed or failed.@@ -147,33 +137,29 @@ yellow diamond. \subsection{The \gddatasetsview{}} \gdhelpid{guidancerDataSetViewContextId}{Data Sets View}-The \gddatasetsview{} is in the lower right-hand corner of the specification perspective by default. It lets you add, modify, delete and see any data for \gdcases{}. For each \gdcase{} containing references, you can add data sets in this view. This is also the view where you can translate your data and overwrite data when you reuse a \gdcase{}. +The \gddatasetsview{} is in the lower right-hand corner of the \specpersp{} by default. It lets you add, modify, delete and see any data for \gdcases{}. For each \gdcase{} containing references or for each central test data set, you can add data sets in this view. This is also the view where you can translate your data and overwrite data when you reuse a \gdcase{}. When data in the \gddatasetsview are uneditable, they are shown in gray. Values in black may be edited. To make entering data easier, pressing \bxkey{Enter} will spring to the next cell or row, or to the \bxcaption{Add} button if no more rows have been added. The \bxkey{Tab} key springs to the \bxcaption{Add} button. \subsection{The \gdcompnamesview{}} \gdhelpid{compNameViewContextId}{Component Names}-The \gdcompnamesview{} is in the lower right-hand corner of the specification perspective by default, just behind the \gddatasetsview{}. It lets you see the component names used in a reused \gdcase{}, and add more component names. This means that you can use a \gdcase{} to execute the same actions on different components. +The \gdcompnamesview{} is in the lower right-hand corner of the \specpersp{} by default, just behind the \gddatasetsview{}. It lets you see the component names used in a reused \gdcase{}, and add more component names. This means that you can use a \gdcase{} to execute the same actions on different components. \subsection{The \gdtestresultview{}} \gdhelpid{testResultViewContextId}{Test Results View} -The \gdtestresultview{} is in the middle of the execution perspective by default. It can also be displayed in the bottom right-hand corner of the specification perspective via the preferences. It follows and displays the results of the test execution. Each \gdstep{} and \gdcase{} is marked with a green tick or a red cross depending on if it passed or failed. +The \gdtestresultview{} is in the middle of the \execpersp{} by default. It can also be displayed in the bottom right-hand corner of the \specpersp{} via the preferences. It follows and displays the results of the test execution. Each \gdstep{} and \gdcase{} is marked with a green tick or a red cross depending on if it passed or failed. -If you select an item in the \gdtestresultview{}, you can see its details in the \gdpropview{} in the execution perspective. If you double-click on a \gdstep{} or \gdcase{} in the \gdtestresultview{}, it will be highlighted in the \gdtestsuitebrowser{} in the execution perspective. Double-clicking on this item in the \gdtestsuitebrowser{} will open the editor for this item in the specfication perspective. --You can also find specified \gdcases{} by right-clicking on an item in the \gdtestresultview{} and selecting \bxcaption{show specification}. +If you select an item in the \gdtestresultview{}, you can see its details in the \gdpropview{}. If the \gdproject{} is open and the item is still available, you can double-click on a \gdstep{} or \gdcase{} in the \gdtestresultview{}, to highlight it in the \gdtestsuitebrowser{}. Double-clicking on this item in the \gdtestsuitebrowser{} will open the editor for this item in the \specpersp{}. \subsection{The \gdprobview{}} \gdhelpid{problemViewContextId}{Problem View}-The \gdprobview{} is by default at the bottom of the specification perspective, under the editor area. The \gdpropview{} helps you to work with \app{} by giving you information, warnings and errors. Double-clicking on a message will either carry out the necessary action or open a dialog/editor to sort out the problem, if this is possible. +The \gdprobview{} is by default at the bottom of the \specpersp{}, under the editor area. The \gdpropview{} helps you to work with \app{} by giving you information, warnings and errors. Double-clicking on a message will either carry out the necessary action or open a dialog/editor to sort out the problem, if this is possible. \subsection{The search result view} \gdhelpid{searchResultViewContextId}{Search Result View}-The search result view (\bxfigref{showresultview}) is at the bottom of the specification perspective, under the editor area, and just behind the \gdprobview{} by default. When you choose to see where a \gdcase{} has been reused, the places where it has been reused are listed in this view. If you double-click on an item in the search result view, the corresponding item is highlighted in the \gdtestcasebrowser{} or \gdtestsuitebrowser{}. --+The search result view (\bxfigref{showresultview}) is at the bottom of the \specpersp{}, under the editor area, and just behind the \gdprobview{} by default. If you perform searches with \app{}, the results are shown here. If you double-click on an item in the search result view, the corresponding item is highlighted in the \gdtestcasebrowser{} or \gdtestsuitebrowser{}. \begin{figure}[hbtp] \begin{center}@@ -185,22 +171,20 @@ The search result view (\bxfigref{showresultview}) is at the bottom of the speci \subsection{The \gdnavview{}} \protect\gdhelpid{org.eclipse.ui.resource_view_context}{Navigator View}-The \gdnavview{} is at the top right-hand corner of the modeling perspective by default. The \gdnavview{} gives you a view of your workspace and can be used to manage your modeling \gdprojects{} as well as test data and test reports. +The \gdnavview{} is at the top right-hand corner of the workspace perspective by default. The \gdnavview{} gives you a view of your workspace and the files in it. -\subsection{The outline view}-The outline view provides an overview of the \gdmodeleditor{}. If you have zoomed in in the editor, or if your model is larger than the editor itself, you can use the outline to orient yourself in the \gdmodeleditor{}. \subsection{The console}-The console is underneath the \gdmodeleditor{} in the modeling perspective and behind the \gdcompnamesview{} lets you follow certain processes in \app{}, for example, the import of \gdprojects{}, validation of models and model generation. +The console is shown in the bottom right-hand corner of the \specpersp{}. It lets you follow certain processes in \app{}, for example, the import of \gdprojects{}. \subsection{The \gdinspector{}}-The \gdinspector{} can be used to help you test RCP \gdauts{} which use the GEF framework. When the inspector is activated, figures can be clicked in the GEF canvas, and their textpath (used to identify them in the test) is shown. The \gdinspector{} is shown by default in the bottom right-hand corner of the specification perspective. +The \gdinspector{} can be used to help you test RCP \gdauts{} which use the GEF framework. When the inspector is activated, figures can be clicked in the GEF canvas, and their textpath (used to identify them in the test) is shown. The \gdinspector{} is shown by default in the bottom right-hand corner of the \specpersp{}. \subsection{The \gdtestsummaryview{}} The \gdtestsummaryview{} offers an overview of all tests that have run in this \gddb{}. It can be filtered and sorted. The \gdtestsummaryview{} is displayed in the \reportpersp{}. \subsection{The \gdrunautview{}}-The \gdrunautview{} is above the \gdtestsuitebrowser{} in the specification perspective. It shows an overview of all running \gdauts{} and can be used to stop \gdauts{} and to start \gdsuites{}. +The \gdrunautview{} is above the \gdtestsuitebrowser{} in the \specpersp{}. It shows an overview of all running \gdauts{} and can be used to stop \gdauts{} and to start \gdsuites{}. \subsection{The \gdimgview{}} The \gdimgview{} is used to see automatically generated screenshots of errors that have occurred in tests.