Tutorial - gsi-upm/BeastTool GitHub Wiki

This page exposes a tutorial to used Beast Tool according with the methodology proposed (Beast Methodology) in the ITMAS2012 paper (http://scholar.google.es/citations?view_op=view_citation&hl=es&user=mT3KgXUAAAAJ&citation_for_view=mT3KgXUAAAAJ:Tyk-4Ss8FVUC).

This tutorial contains the following sections:

0. Example project

Let's say that we want to develop a system to receive notification of errors from customers which automatically create an issue report. The system must process these reports and classify them. (Yes, it is a really simple example. But this is a tutorial for Beast beginners. ;) )

To learn how to use Beast Methodology, we are going to create a project with only one agent (developed in both JADE4.0 and JADEX2.0).

Following the four phases proposed in Beast (BEhavioural Agent Simple Testing) Methodology:

  • System Behaviour Specification
  • MAS Behaviour Specification
  • Agent Level Testing
  • MAS Level Testing

We must specify a set of requirements for the whole system in User Story format. Later, we must decompose that requirements in Agent Story format to specify the agent requirements. And finally, we must perform any developed test.

Note: The code of this tutorial is available in the project repository as "beast-tutorial" project. But we recommend to follow this tutorial and only check that code as reference.

### 1. Create Maven project

To continue this tutorial, we recommend to use Eclipse and Maven. If you don't know how to use them, please go to developer manual where how to work with Maven and Eclipse together. Once all is installed:

  1. Open Eclipse and create a new project:
  2. File-> New-> Project, Maven folder-> Maven Project
  3. Write the name of your project in "Artifact ID" and Finish.

### 2. Add Beast dependency

In the project pom.xml file, add a new dependency to Beast.

<dependencies>
	<dependency>
		<groupId>es.upm.dit.gsi</groupId>
		<artifactId>beast-tool</artifactId>
		<version>0.9.8</version>
	</dependency>
</dependencies>

Of course, you can modify the version, or even remove it to use the last one.

Note: This tutorial is written for 0.9.8 (or higher) version.

To import any dependency required by Beast, add this code to your pom.xml

<dependencyManagement>
	<dependencies>
		<dependency>
			<groupId>es.upm.dit.gsi</groupId>
			<artifactId>beast-tool</artifactId>
			<version>0.9.8</version>
			<type>pom</type>
			<scope>import</scope>
		</dependency>
	</dependencies>
</dependencyManagement>

Note: We strongly recommend to use Maven from console, since we have found several bugs in m2eclipse plugin. So, ensure that you have properly configured Maven in your console. See Developer Manual if you don't know about maven.

3. Write system specification requirements.

Remember that we said above that we want to develop a system to receive notification of errors from customers which automatically create an issue report. The system must process these reports and classify them. That is the specification of our system.

Now, we have to translate that in User Stories (see the paper referred above to understand this terminology and the story format).

  1. Create a new File, for example, in "src/test/resources/stories/system" inside your project and name it Inbox.story.
  2. Open that file and write in plain text a User Story which represents a feature. In this case, the feature is that the system must be able to receive reports.
Story: Inbox service 
As a helpdesk operator,
I want to have a system that receives any report generated by customers,
So that I save effort and time since less phone calls are received.

This User Story represents a feature required by a helpdesk operator. Now, it must be exemplified with a set of specific scenarios. In the same file (Inbox.story), append any number of scenarios. Here we only write two scenario to simplify the tutorial:

Scenario: Report creation
Given a customer has a problem,
When a phone call is received
And the voice recognition system understands to the customer,
Then the system records the message
And a new issue report is created.
Scenario: Passing incoming call
Given a customer is calling,
When the voice recognition system does not understand to the customer,
Then the call is attended by a helpdesk operator.

Let's say that all system features are already specified with this story and its two scenarios. Then, following Beast Methodology, System Behaviour Specification phase is finished.

4. Configure Beast Tool to parse "User Stories"

Now, we have to create two configuration files.

The first one:

src/test/resources/beast-conf/logger.properties

It is a standard properties file of Java Logger. For this example, we use this configuration:

handlers = java.util.logging.ConsoleHandler
.level=ALL
java.util.logging.ConsoleHandler.level=INFO
java.util.logging.ConsoleHandler.formatter=java.util.logging.SimpleFormatter

The second one:

src/test/resources/beast-conf/system/beast-systemphase-conf.properties

With the following content:

srcTestRootFolder=src/test/java
storiesPackage=beast.tutorial.stories.system
requirementsFolder=src/test/resources/stories/system/
caseManagerPackage=beast.tutorial.manager
specificationPhase=SYSTEM

Here it is a brief summary about these properties. To know all about them, please reader the User Manual wiki page.

  • srcTestRootFolder where all our test java classes are found. Tipically, it is src/test/java.
  • storiesPackage, inside the previous folder, all java classes will be created in this package.
  • requirementsFolder where all .story files are stored.
  • caseManagerPackage where the case manager is created or where is actually stored (to append new test cases). In this package, the case manager is generated: "UserStoriesManager.java" or "AgentStoriesManager.java", depending of the next property.
  • specificationPhase to specify the testing phase we are performing. It can be "SYSTEM" or "MAS".

Once your configuration files are ready, you must configure your pom.xml to launch Beast Tool during your test phase. Insert the following plugin configuration in your project pom.xml.

<build>		
	<plugins>
		<plugin>
			<groupId>org.codehaus.mojo</groupId>
			<artifactId>exec-maven-plugin</artifactId>
			<version>1.1.1</version>
			<executions>
				<execution>
					<id>Beast Test Resources Generation - System Phase</id>
					<phase>generate-test-sources</phase>
					<goals>
						<goal>java</goal>
					</goals>
					<configuration>
						<mainClass>es.upm.dit.gsi.beast.reader.Reader</mainClass>
						<arguments>
							<argument>src/test/resources/beast-conf/system/beast-systemphase.properties</argument>
							<argument>src/test/resources/beast-conf/logger.properties</argument>
						</arguments>
					</configuration>
				</execution>
			</executions>
		</plugin>
	</plugins>
</build>

Note: sometimes in eclipse, this code highlights an error that says:

"Plugin execution not covered by lifecycle configuration: org.codehaus.mojo:exec-maven-plugin:1.1.1:java (execution: Beast Test Resources Generation, phase: generate-test-sources)"

It does not matter, don't worry. You can run "mvn test" in the console without any problem. You can say to Eclipse to ignore it.

Now, you must execute "mvn test" command in your console. In other words, go to your project root folder in the console and then, execute the command "mvn test".

After a successful execution, some Java classes will be generated. With the configuration shown previously, the result is the following:

src/test/java
	beast.tutorial
		manager
			UserStoriesManager.java
		stories.system
			InboxService.java

UserStoriesManager.java contains is a test suite that contains all parsed stories to execute all test easily. InboxService.java contains all scenarios specified in the story file. This class must be completed by the designer in the next steps of the methodology.

5. Design your Multi-Agent System

Once we have obtained user requirements in the previous phase, we can start to design our agents.

Note: Beast Methodology is an agile testing methodology, so the MAS designer can use any AOSE methodology.

Now, let's say that based on the requirements exposed in section 3. Write System Specification requirements, we have designed three different agents or roles (following any design methodology).

  • HelpDeskAgent: this agent has access to the computer of the human operator.
  • RecorderAgent: this agent records messages from customer incoming calls.
  • ReporterAgent: this agent stores reports of received messages.

Now, let's say that we write only one story per agent. Obviously, you can specify any number of stories per agent, but for teaching purposes, three are enough.

Make a new directory:

src/test/resources/stories/mas

In this directory, create the following files following the same principles than in section 3. Write System Specification requirements. But now, instead of from the customer/user point of view, from an agent point of view.

Incoming call.story

Story: Record a message
As a RecorderAgent,
I want to record incoming calls,
So that I can pass the message to a ReporterAgent.

Scenario: Misunderstanding the customer
Given a RecordAgent and a HelpDeskAgent can communicate between them, 
When a phone call is received
And the RecorderAgent does not understand the customer,
Then the RecorderAgent sends a FIPA-REQUEST message to a HelpDeskAgent
And the RecorderAgent pass the incoming call to a HelpDeskAgent.

Scenario: Understanding the customer
Given a RecordAgent and a ReporterAgent can communicate between them,
When a phone call is received
And the RecordAgent understands the customer,
Then the RecordAgent records his/her message
And the RecordAgent sends that FIPA-INFORM message to a ReporterAgent.

Passing call.story

Story: Passing an incoming call
As a HelpDeskAgent,
I want to process a FIPA-REQUEST message from a RecorderAgent,
So that I am able to pass an incoming call to a human operator.

Scenario: Pass a call
Given a HelpDeskAgent has connection to the desktop of the operator computer,
And a RecorderAgent has received a call that cannot understand,
When that HelpDeskAgent receives a FIPA-REQUEST message from that RecorderAgent,
Then the request is accepted and the incoming call is transfered to the human operator.  

Creating issue report.story

Story: Processing message
As a ReporterAgent,
I want to process any FIPA-INFORM message from a RecorderAgent which contains a recorded message,
So that I am able to generate an issue report based on that message content.

Scenario: Create a report
Given a ReporterAgent has access to the database,
And a RecorderAgent has received a call that can understand,
When that ReporterAgent receives a FIPA-INFORM message from that RecorderAgent,
Then the message is processed
And a new issue report is created.

With these three files, let's say that we have the behaviours of our agent completely defined. At this point of the tutorial we are going to implement the MAS with JADE and JADEX. Of course, if you use Beast Tool in your project, you should use only one of them...

6. Configure Beast Tool to parse "Agent Stories"

This step is similar to step 4. But now, we have a bit different configuration file and results.

Make a new directory:

src/test/resources/beast-conf/mas

Now, create two files (for JADE and JADEX respectively).

jade-beast-masphase-conf.properties

srcTestRootFolder=src/test/java
storiesPackage=beast.tutorial.jade.stories.mas
requirementsFolder=src/test/resources/stories/mas/
caseManagerPackage=beast.tutorial.jade.manager.mas
specificationPhase=MAS
MASPlatform=jade

jadex-beast-masphase-conf.properties

srcTestRootFolder=src/test/java
storiesPackage=beast.tutorial.jadex.stories.mas
requirementsFolder=src/test/resources/stories/mas/
caseManagerPackage=beast.tutorial.jadex.manager.mas
specificationPhase=MAS
MASPlatform=jadex

As you can see, we have modified "specificationPhase" property and added "MASPlatform" one. To execute, BeastTool with these configuration, we add some code to the project pom.xml. This should be the configuration of the "exec-maven-plugin" to execute, all our configurations.

	<plugin>
			<groupId>org.codehaus.mojo</groupId>
			<artifactId>exec-maven-plugin</artifactId>
			<version>1.1.1</version>
			<executions>
				<execution>
					<id>Beast Test Resources Generation - System Phase</id>
					<phase>generate-test-sources</phase>
					<goals>
						<goal>java</goal>
					</goals>
					<configuration>
						<mainClass>es.upm.dit.gsi.beast.reader.Reader</mainClass>
						<arguments>
							<argument>src/test/resources/beast-conf/system/beast-systemphase-conf.properties</argument>
							<argument>src/test/resources/beast-conf/logger.properties</argument>
						</arguments>
					</configuration>
				</execution>
				<execution>
					<id>Beast Test Resources Generation - MAS Phase - JADEX</id>
					<phase>generate-test-sources</phase>
					<goals>
						<goal>java</goal>
					</goals>
					<configuration>
						<mainClass>es.upm.dit.gsi.beast.reader.Reader</mainClass>
						<arguments>
							<argument>src/test/resources/beast-conf/mas/jadex-beast-masphase-conf.properties</argument>
							<argument>src/test/resources/beast-conf/logger.properties</argument>
						</arguments>
					</configuration>
				</execution>
				<execution>
					<id>Beast Test Resources Generation - MAS Phase - JADE</id>
					<phase>generate-test-sources</phase>
					<goals>
						<goal>java</goal>
					</goals>
					<configuration>
						<mainClass>es.upm.dit.gsi.beast.reader.Reader</mainClass>
						<arguments>
							<argument>src/test/resources/beast-conf/mas/jade-beast-masphase-conf.properties</argument>
							<argument>src/test/resources/beast-conf/logger.properties</argument>
						</arguments>
					</configuration>
				</execution>
			</executions>
		</plugin>

Of course, if you want to develop a system using JADE or JADEX, you must add those dependencies to your pom.xml. JADEX are available in Maven repositories. But JADE must be installed manually in your Maven local repository with the following commad:

mvn install:install-file -DgroupId=com.tilab -DartifactId=jade -Dversion=4.0 -Dpackaging=jar -Dfile=/path/to/jarfile	

Of course, "path/to/jarfile" must be modified.

Note: Since JADEX has a lot of dependencies, we are not going to write them here. But, you can check that dependencies in the pom.xml that is available in the project repository in the beast-tutorial project.

Now, when you have all these files properly configured, execute "mvn test" in your project root folder. A set of Java classes will be generated in the folders/packages specified in your configuration files.

7. Providing traceability

Once we have generated both "User Stories" and "Agent Stories", the MAS designer must provide traceability among both requirement sets.

Following the configuration files shown above, the "User Stories" (i.e. the system requirements) are stored in src/test/java/beast/tutorial/stories/system. There we find the InboxService.java class. Open it and find these methods:

@Test
public void passingIncomingCall() {
}

@Test
public void reportCreation() {
}

These methods represent both scenarios written in the .story file presented in section 3. Write System Specification requirements.

Reading the behaviour specified in the three "AgentStories" exposed above, we detect that the second scenario (passingIncomingCall) of the "UserStory" is related with the first scenario of the Incoming call.story file and with the whole story of the Passing call.story file. Thus, we are going to launch those tests to ensure this user requirement is met.

It is important to remark that we want to launch a concrete scenario part of one story and a complete story with all its scenarios.

This is the example code to launch a concrete scenario:

BeastTestCaseRunner.executeBeastTestCase("beast.tutorial.jade.stories.mas.recordAMessage.UnderstandingTheCustomer");

This is the example code to launch a complete story:

Result jadeResult = JUnitCore.runClasses(beast.tutorial.jade.stories.mas.PassingAnIncomingCall.class);
Assert.assertTrue(jadeResult.wasSuccessful());

So, passingIncomingCall method should be filled in like the following one:

    @Test
	public void passingIncomingCall() {
		//JADE tests
		BeastTestCaseRunner.executeBeastTestCase("beast.tutorial.jade.stories.mas.recordAMessage.MisunderstandingTheCustomer");

        Result jadeResult = JUnitCore.runClasses(beast.tutorial.jade.stories.mas.PassingAnIncomingCall.class);
        Assert.assertTrue(jadeResult.wasSuccessful());
    
        //JADEX tests
    	BeastTestCaseRunner.executeBeastTestCase("beast.tutorial.jadex.stories.mas.recordAMessage.MisunderstandingTheCustomer");
    
    	Result jadexResult = JUnitCore.runClasses(beast.tutorial.jadex.stories.mas.PassingAnIncomingCall.class);
        Assert.assertTrue(jadexResult.wasSuccessful());        
    }

Note: In a regular project, you only use JADE or JADEX, not both at the same time.

The second scenario of the "UserStory" (reportCreation) is related with the rest of the "AgentStories". So, reportCreation method should be filled in like the following one:

	@Test
	public void reportCreation() {
    	// JADE tests
		BeastTestCaseRunner.executeBeastTestCase("beast.tutorial.jade.stories.mas.recordAMessage.UnderstandingTheCustomer");

    	Result jadeResult = JUnitCore.runClasses(beast.tutorial.jade.stories.mas.ProcessingMessage.class);
    	Assert.assertTrue(jadeResult.wasSuccessful());

    	//JADEX tests
		BeastTestCaseRunner.executeBeastTestCase("beast.tutorial.jadex.stories.mas.recordAMessage.UnderstandingTheCustomer");

    	Result jadexResult = JUnitCore.runClasses(beast.tutorial.jadex.stories.mas.ProcessingMessage.class);
    	Assert.assertTrue(jadexResult.wasSuccessful());
	}

With these two pieces of code in src/test/java/beast/tutorial/stories/system/InboxService.java, we have provided traceability from "UserStories" to "AgentStories" and then any user requirements can be directly tested in the code.

8. Implementing tests

Now, we start to implement these tests. We don't have implemented our system or our data model. We have nothing more than the tests classes auto-generated by Beast Tool. So, we are going to use mock objects and mock agents to implement our tests.

Note: See mockito project in Google Code or Github.

https://code.google.com/p/mockito/

https://github.com/mockito/mockito

Note: To know what is a mock object, visit this Wikipedia page: http://en.wikipedia.org/wiki/Mock_object

So, we are going to Mockito framework to mock our objects.

8.1 Defining data model

Let's start defining our data model. Our agents are going to use these Java classes as beans:

  • Call, to model the concept of model.
  • CallQueue, to have a queue to store incoming calls.
  • Customer, to model the customer, his/her language, etc.
  • Message, to model a message from a customer.
  • Report, to model an issue report.

With these classes, our multi-agent system will work to achieve their goals and to share information. Now, we create this classes in:

src/main/java/
	beast.tutorial.tools
		Call.java
		CallQueue.java
		Customer.java
		Message.java
		Report.java

Of course, these classes are empty and they will be implemented later. For this reason we must use mock agents. To be able to mock agents, we must define the methods that will be mocked.

For example, we add this code to CallQueue.java class:

/**
 * @return
 */
public Call getPendingCall() {
	return null;
}

or this code to Call.java

/**
 * @return
 */
public Customer getCustormer() {
	return null;
}

We don't need to implement those methods, only we define it to mock them later.

Note: The rest of the methods can be checked in the code of the beast-tutorial project.

8.2 Configuring Mocks

We must distinguish now two types of mocks: Mock Agents and Mock Objects. Both follow the same principles, but while some tools offer the capabilities to use mock objects, no mock agents tool has found (and, of course, no multi-platform mock agent tool has found...). So, we have develop several Mock Agents that use Mocked Object to configure their behaviours.

Note: the following code is an example. You don't have to put it in any class yet.

So, we can mock the response of an object (or objects):

	// Creating mocks objects
	CallQueue queue = mock(CallQueue.class);
	Call call = mock(Call.class);
	Customer customer = mock(Customer.class);

	// Defining mock behaviours
	when(customer.getLanguage()).thenReturn("English");
	when(call.getCustormer()).thenReturn(customer);
	when(queue.getPendingCall()).thenReturn(call).thenReturn(call).thenReturn(null);

	setBeliefValue("RecorderAgentUnderTesting", "queue", queue);

Or, we can mock the response of an agent:

    // ReporterJADEXMockAgent configuration
   AgentBehaviour myMockedBehaviour =   mock(AgentBehaviour.class);
   MockConfiguration mock_configuration = new MockConfiguration();
   mock_configuration.setDFServiceName("report-service");
   mock_configuration.setBehaviour(myMockedBehaviour);
   MockManager.startMockJadexAgent("ReporterMockAgent",Definitions.JADEX_LISTENER_MOCK_PATH,mock_configuration,this);


    // ReporterJADEMockAgent configuration
    AgentBehaviour myMockedBehaviour = mock(AgentBehaviour.class);
    MockConfiguration mock_configuration = new MockConfiguration();
    mock_configuration.setDFServiceName("report-service");
    mock_configuration.setBehaviour(myMockedBehaviour);
    MockManager.startMockJadeAgent("ReporterMockAgent",Definitions.JADE_LISTENER_MOCK_PATH, mock_configuration, this);

For further reading, check User Manual wiki page or the test set implemented in beast-tutorial example project.

8.3 A BestTestCase

Summarising, using our model and our mock agents/object. We can implement any test obtaining the following result:

public class UnderstandingTheCustomer extends BeastTestCase {
	public void setup() {
    	// Launch RecordAgent
        startAgent("RecorderAgentUnderTesting",
                "beast.tutorial.jade.agent.RecorderAgent",
                "MyContainer", null);
        
        // ReporterMockAgent configuration
        AgentBehaviour myMockedBehaviour = mock(AgentBehaviour.class);
        MockConfiguration mock_configuration = new MockConfiguration();
        mock_configuration.setDFServiceName("report-service");
        mock_configuration.setBehaviour(myMockedBehaviour);
        MockManager.startMockJadeAgent("ReporterMockAgent",
                Definitions.JADE_LISTENER_MOCK_PATH, mock_configuration, this);
    }

    public void launch() {
    	// Creating mocks objects
    	CallQueue queue = mock(CallQueue.class);
    	Call call = mock(Call.class);
    	Customer customer = mock(Customer.class);

    	// Defining mock behaviours
    	when(customer.getLanguage()).thenReturn("English");
    	when(call.getCustormer()).thenReturn(customer);
    	when(queue.getPendingCall()).thenReturn(call).thenReturn(null);
        
        setBeliefValue("RecorderAgentUnderTesting", "queue", queue);
    }

    public void verify() {
        checkAgentsBeliefEquealsTo("ReporterMockAgent", Definitions.RECEIVED_MESSAGE_COUNT, 1);
    }
}

The previous example is the implementation of one scenario exposed in an "AgentStory". A lot of comments have been ommited to simplify the reading of the example. But the whole code can be found in:

	src/test/java
		beast.tutorial.jade.stories.mas.recordAMessage.UnderstandingTheCustomer.java

9. Implementing agents

Once all our test has been defined, we can implement our agents in parallel since we are using mock agents to replace non-implemented ones. The scope of this tutorial is to teach how to use Beast Methodology and Beast Tool. Thus, we are not going to explain how to implement the agents of this project.

However, you can find the implementation of these three agents in JADE 4.0 and in JADEX 2.0 in:

	src/main/java
		beast.tutorial.jadex.agent
		beast.tutorial.jade.agent

10. Testing agents

Once we have implemented any feature of any agent, we can test it from Eclipse like any JUnit test. To add those tests to the Maven test phase (i.e. to execute those tests when you execute "mvn test" command), you must add this code to your project pom.xml file:

		<plugin>
			<groupId>org.apache.maven.plugins</groupId>
			<artifactId>maven-surefire-plugin</artifactId>
			<version>2.11</version>
			<configuration>
				<phase>test</phase>
				<includes>
					<include>**/*Test.java</include>
					<include>beast/tutorial/manager/UserStoriesManager.java</include>
					<include>beast/tutorial/jadex/manager/mas/AgentStoriesManager.java</include>
					<include>beast/tutorial/jade/manager/mas/AgentStoriesManager.java</include>
				</includes>
				<parallel>false</parallel>
				<threadCount>1</threadCount>
				<perCoreThreadCount>false</perCoreThreadCount>
				<useUnlimitedThreads>false</useUnlimitedThreads>
			</configuration>
		</plugin>

Adding these labels, you can add any JUnit TestCase or TestSuite to Maven Test Phase. In this case, we have added both "StoriesManagers" that executes all test in one TestSuite, but you can add one or more stories independently if you like.

11. Integration tests

Once we have tested all our agents by themselves, we can integrate our implemented agents and test them together. As we have used Mock Agents in the previous tests, our integration tests will consist in replace that Mock Agents for real implemented agents.

To keep unitary tests and integration tests separated, we are going to created another test set for integration purposes. Once again, we add two configuration files in src/test/resources/beast-conf/mas:

integration-jade-beast-masphase-conf.properties srcTestRootFolder=src/test/java storiesPackage=beast.tutorial.jade.integration.stories.mas requirementsFolder=src/test/resources/stories/mas/ caseManagerPackage=beast.tutorial.jade.integration.manager.mas specificationPhase=MAS MASPlatform=jade

integration-jadex-beast-masphase-conf.properties srcTestRootFolder=src/test/java storiesPackage=beast.tutorial.jadex.integration.stories.mas requirementsFolder=src/test/resources/stories/mas/ caseManagerPackage=beast.tutorial.jadex.integration.manager.mas specificationPhase=MAS MASPlatform=jadex

And we add these code to pom.xml to generate test cases skeletons in the mvn generate-test-sources phase. We must add this code in the exec-maven-plugin configuration, as previously with the other configuration files.

			<execution>
				<id>Beast Test Resources Generation - MAS Phase - JADE Integration</id>
				<phase>generate-test-sources</phase>
				<goals>
					<goal>java</goal>
				</goals>
				<configuration>
					<mainClass>es.upm.dit.gsi.beast.reader.Reader</mainClass>
					<arguments>
						<argument>src/test/resources/beast-conf/mas/integration-jade-beast-masphase-conf.properties</argument>
						<argument>src/test/resources/beast-conf/logger.properties</argument>
						</arguments>
				</configuration>
			</execution>
			<execution>
				<id>Beast Test Resources Generation - MAS Phase - JADEX Integration</id>
				<phase>generate-test-sources</phase>
				<goals>
					<goal>java</goal>
				</goals>
				<configuration>
					<mainClass>es.upm.dit.gsi.beast.reader.Reader</mainClass>
					<arguments>
						<argument>src/test/resources/beast-conf/mas/integration-jadex-beast-masphase-conf.properties</argument>
						<argument>src/test/resources/beast-conf/logger.properties</argument>
						</arguments>
				</configuration>
			</execution>

Now, we have to execute "mvn test" again to execute this two configurations of BeastTool to get more test cases. The obtained test cases must be implemented like the previous one, with the exception that no mock agents should be used.

12. Test your project

In this final step, all tests and all configurations should be properly implemented/written to test you whole project using only one command: "mvn test". This should execute:

  • your "AgentStories", with unitary tests and integration tests.
  • your "UserStories" as test suites which launch other "AgentStories" as test suites too or only scenarios as BeastTestCases.

Summarising, the result of this tutorial can be found in beast-tutorial project in the project repository. If any problem is found during the reading, you can download and check that project or ask to us. :)

Thank you very much for your time.

13. Future work

To finish this methodology and its support with the developed tool, we are working in a final phase to simulate complex environments in where all implemented agents must be tested together. By now we are working in the integration process of this tool with MASON http://cs.gmu.edu/~eclab/projects/mason/ (for simulation) and with JASON http://jason.sourceforge.net/wp/ (to support other agent platforms).

⚠️ **GitHub.com Fallback** ⚠️