Confluence is an enterprise wiki that makes it easy to create and share documents. |
Table of Contents
The installation of is no different from any other Confluence Add-On installation.
Simply upload your livingdoc-confluence-plugin-xx.jar via your Add-On Manager.
The upgrade of is no different from any other Confluence plugin upgrade.
1. Uninstall your Plugin via your Add-On Manager
2. Re-Upload your Plugin via your Add-On Manager
If you really want to uninstall , simply uninstall your Plugin via your Add-On Manager
If you expose the Confluence server to the outside world (other than localhost), make sure the Server Base URL of Confluence found is the external URL of the server. This property is found under the General Configuration of the Administration of Confluence. Note : If you change this URL when existing Spaces have been registered as LivingDoc project, you will need to refresh each project by clicking the Edit link then the Save link on the Space Registration form of the Space Administration or on the Project Management tab of the configuration of the LivingDoc plugin. |
Here are the panes that will be accessible from your Toolbox plugin Configuration.
has its own database to store multiple data such as executions results, references and so on.
You will have two options:
Your runners configuration pane.
You will be able to add/remove/update your runners.
We recommend creating an own remote runner because tests must be run outside of the confluence VM.
The most recent Java runner will be available by default. At each start of Confluence, we make sure there is a Java Runner matching the plugin version. |
You can set different classpaths to the same Runner(e.g. different folder locations for Linux- and Windows-Users). Delimitate paths with a NewLine(Enter). During runtime every non existing path will be ignored. Please ensure the data consistency of two or more Runners of the same name and package but a different and existing path. The easiest way to achieve this, is to keep your project up-to-date via version control systems like Git or Subversion. |
The goal of the repository registration is to regroup available specifications and requirements repositories under a single common project so that, when linking specifications to requirements, we can concentrate on related repositories. Here is an overview of the domain:
To register your repository to server, follow these steps:
Enter the Classpath, where your LivingDoc-Classes(Fixtures) can be found
You can set different classpaths to the same project(e.g. different folder locations for Linux- and Windows-Users). Delimitate paths with a NewLine(Enter). While executing tables every non existing path will be ignored. Please ensure the data consistency of two or more classes of the same name and package but a different and existing path. The easiest way to achieve this, is to keep your project up-to-date via version control systems like Git or Subversion. |
If you have upgraded LivingDoc maybe is necessary to migrate the space in order to add the LivingDoc Header to all specifications. After register a repository a Migrate space button appears in the right side of the window.
After click on it you can see all pages that will be updated.
Then you can press on Launch. Done, your space has been migrated.
After migrate only specifications with LivingDoc Header enabled will be migrated. In case you need to execute one which was not a specification you should add a Page Macro manually. |
The Theme is a plug-and-play plugin giving access to all functionalities once it has been set.
You can set the Theme from the Space admin panel or Global admin panel.
The drawback of using the Theme is that you will not be able to customize your layouts (e.g. page, space, template) or, if already customized, your customization will be ignored.
Two themes are available.
We cannot guaranty the behavior of the theme between Confluence upgrades. We do not have control on the default page layout of Confluence. This one may vary from a version to another. We advise you to manually configure your page layout. See Confluence Plugin Setup. |
First, you need to add the following to your Page Layout :
To allow remote access to the the addon, it is necessary to activate the Remote API. Go to the menu Further Configuration of your confluence installation and check the box next to Remote API (XML-RPC & SOAP).
As you might have already noticed, in versions previous to 1.4.x, pages in registered spaces have a checkbox labeled LivingDoc enabled. Checking it will automatically register the document in the server. The default System Under Test will be automatically associated to your newly executable page.
Since v1.4.x pages in registered spaces should have a Page Macro inserted to execute the specification.
Over the three points in the button "Create" in Confluence you can create an empty LivingDoc Specification page with the LivingDoc Header.
Choose "LivingDoc Specification".
After save you can see a page with the Livingdoc header.
You might want to associate your page to other Systems Under Test. To do so, click the Configuration button.
You can now remove or add System Under Test associations. This is important if you want the livingdoc-labels or livingdoc-children macro to select your page.
You can now Execute your page. Next to the Execute button you will find which System Under Test will be involved. If you need to select another System Under Test, click the Edit button and select the desired System Under Test. The dropdown list only contains the Systems Under Test configured in step I.
You will see in the right-hand side of your header the version information of your page.
There is two possible states:
Both states are executable. |
The most recent version is the Implemented version
The Implemented version
The most recent version differs from the Implemented version
Clicking on Set as Implemented will set the current version of the page as the Implemented version.
An easy revert feature is provided. Reverting will set the previous implemented version as the actual implemented version.
Description: This macro enables the page as executable specification. It adds an execution button, SUT configuration, switching between working and implemented version and status bar for the execution results.
Syntax: {livingdoc-page-macro}
EXAMPLE | |
---|---|
|
Description: This macro can execute a batch of documents resulting from a page hierarchy.
Syntax: {livingdoc-children}
Optional parameters:
EXAMPLE | |
---|---|
|
Description: This macro allows you in the lazy mode to annotate tables and/or bullet lists that you do want to be processed as executable specifications within your executable documents.
Syntax: {livingdoc-example} your example table(s)/list(s) {livingdoc-example}
Optional parameters:
If you omit to close your example section, the end of the document will be considered as the end of it |
Description: This macro creates a Chart image of the latest historic data of a page execution. The image created provide clickable area to display the specific execution result.
Syntax: {livingdoc-historic}
Optional parameters:
EXAMPLE 1 | |
---|---|
|
When executing specification locally or through a continuous build server, result are not saved automatically since they are disconnected from the Confluence plugin (only the specification page is retrieved).
Starting from version 2.2, we can post back the execution result using the repository implementation info.novatec.testit.livingdoc.runner.repository.LivingDocRepository. A new parameter must be added to the URL : postExecutionResult=true.
Example using the LivingDoc Maven Plugin :
<repositories> <repository> <type>info.novatec.testit.livingdoc.runner.repository.LivingDocRepository</type> <root> <![CDATA[http://.../confluence/rpc/xmlrpc?handler=livingdoc1&sut=Java&includeStyle=false&postExecutionResult=true]]> </root> <name>livingdoc</name> <suites> <suite>LivingDoc Confluence-LivingDoc</suite> </suites> </repository> </repositories> |
Description: This macro allows you to import classes into your executable document without polluting it with undesirable and not meaningful user tables.
Syntax: {livingdoc-import: my.class.to.import | some.other.class.to.import | ... }
EXAMPLE | ||||
---|---|---|---|---|
This will generate the following hidden table:
|
Description: This macro allows you to include pages content into Executable document allowing for example, to define a setup and a tear down page and include it in executable pages avoiding duplication.
Syntax: {livingdoc-include}
Mandatory parameters:
Optional parameters:
EXAMPLE | |
---|---|
|
Description: This macro allows you to create tables and/or bullet lists that you do not want to be processed as executable specifications within your executable documents.
Syntax: {livingdoc-info} your body {livingdoc-info}
Optional parameters:
This macro also allows you to insert into your executable document, other macros that generate tables or bullet lists. |
If you omit to close your info section, the end of the document will be considered as the end of it |
EXAMPLE 1 | ||||
---|---|---|---|---|
|
EXAMPLE 2 | |||||
---|---|---|---|---|---|
|
Description: This macro can execute a batch of documents resulting from a label search.
Syntax: {livingdoc-labels}
Optional parameters:
Example | |||
---|---|---|---|
|
Activating the logs is helpful for the support team.
To activate the logs, browse to the Logging and Profiling menu under the Confluence Administration screens. Under the Add New Entry, specify info.novatec.testit.livingdoc for the Class/Package Name, select the ALL (or DEBUG) level and then click the Add Entry button.
The remote agent is a small server that can be used to execute specifications from a Server to another machine.
This Agent is an answer to many purposes like this examples :
The remote agent is a simple executable java application which is part of LivingDoc.
java -jar livingdoc-remote-agent-x.x-complete.jar |
java -jar livingdoc-remote-agent-x.x-complete.jar -port <MyPortNumber> |
The communication between your server and your agent can be secured with SSL.
On the remote agent
To enable Secured mode start the remote agent with this command line :
java -jar livingdoc-remote-agent-x.x-complete.jar -secured -keystore <path to your keystore file> |
Starting with version 2.1, the remote agent can use a property file to specify parameters (instead of the command line parameters). By default, the remote agent will look for a property file remoteagent.properties in the current directory. You can also use the command line parameter -config [path of the configuration file] to override the default property file.
Command line parameter | Configuration file entry | Default Value |
---|---|---|
-port | livingdoc.remoteagent.port | 56000 |
-secured | livingdoc.remoteagent.secured=[true or false] | false |
-keystore | livingdoc.remoteagent.keystore.file=[path of the keystore file] | * Mandatory if secured=true |
livingdoc.remoteagent.keystore.password=[the password of the keystore file] | * Mandatory if secured=true and the keystore require a password |
The property livingdoc.remoteagent.keystore.password replace the command line input of the keystore password at remote agent startup.
You would need to setup your Web Container to server HTTPS requests. We recommend to use the following official guide from Atlassian for running an confluence installation over SSL or HTTPS:
https://confluence.atlassian.com/display/DOC/Running+Confluence+Over+SSL+or+HTTPS
You would need to tell your runner the location of the trustStore and the password on the command line (Optional if you imported the certificate in the JVM)
java -Djavax.net.ssl.trustStore=c:\livingdoc.cacerts -Djavax.net.ssl.trustStorePassword=[WIP:the password of the trustStore] |
From Confluence / Jira, make sure the base url is using https on port 8443 (goto Adminstration / General Configuration).
If you are using the Eclipse Plugin , you would need to perform the following steps :
Add information about the truststore and password to the eclipse.ini (Optional if you imported the certificate in the JVM)
-Djavax.net.ssl.trustStore=c:\livingdoc.cacerts -Djavax.net.ssl.trustStorePassword=[WIP:the password of the trustStore] |
To be able to create a test case (a link between a requirement and a test document), you need a registered TEST repository such as a space from Confluence and a registered Requirement repository (such as a JIRA project) on the same project. Make sure a system under test has been defined for your project .
Make sure that your confluence space is register in your space settings.
Make sure that your confluence space is assigned to the LivingDoc Documentation Theme in your space settings.
This is because uses some AJAX calls and they cannot occur across multiple domains. Make sure that the domain you are using in the url of your browser matches the domain in the Server Base Url configured in Confluence's General Configuration. A common case of this is when is installed on a local machine. We suggest you use the name of your local machine (http: //mymachine:8080/accept) instead of localhost in the URL (e.g. http: //localhost:8080/accept).