en
de
November 2018

A Plugin for Atlassian Jira – Wired Tests 2

12 December 2000
| |
Reading time: 3 minutes

Previous Page | Next Page | Pages: 0 1 2 3 4 5 6 7

Non-trivial wired test

Assuming that the test passes, add a second test. First define a constant just below the opening brace of the MetricsInfoImplWiredTest class:

final static String userName      = "admin";

Below the first test case, add the second:

@Test
public void shouldReturnProjectLead() {
    final Map contextMap = metricsInfo.getContextMap(null, null);
    final Project project = (Project) contextMap.get(MetricsInfo.PROJECT);
    assertNotNull("Project project should not be null", project);
    assertEquals("Project Lead Name", userName, project.getLeadUserName());
}

The assertTrue import is deleted and the following imports are added:

import com.atlassian.jira.project.Project;
import java.util.Map;
import static org.junit.Assert.*;

This test will fail: the context map is empty. To make the test pass, you will have to set up certain preconditions and pass the correct parameters to the getContextMap call. Firstly, you’ll have to get hold of the UserProjectHistoryManager object used by the module under test. So add a method to the MetricsInfo interface:

UserProjectHistoryManager getUserProjectHistoryManager();

The following import is added to the interface class’s source file:

import com.atlassian.jira.user.UserProjectHistoryManager;

Implement the method in MetricsInfoImpl.java:

@Override
public UserProjectHistoryManager getUserProjectHistoryManager() {
    return this.userProjectHistoryManager;
}

Next, the test class needs a few more constants:

final static String projectName   = "SampleProject";
final static String projectKey    = "SAM";
final static String projectType   = "business";

It also needs a few more fields:

private final Backdoor backdoor;
private final JIRAEnvironmentData environmentData;
private final UserManager userManager;
private final ApplicationUser applicationUser;
private final JiraHelper jiraHelper;
private final UserProjectHistoryManager userProjectHistoryManager;

These fields have to be initialised in the constructor (or inline):

this.environmentData       = new TestKitLocalEnvironmentData(); // localtest.properties supplies defaults
this.backdoor              = new Backdoor(environmentData);
this.userManager           = ComponentAccessor.getUserManager();
this.applicationUser       = userManager.getUserByName(userName);
this.jiraHelper            = new JiraHelper();
userProjectHistoryManager  = metricsInfo.getUserProjectHistoryManager();

The following imports are added:

import com.atlassian.jira.component.ComponentAccessor;
import com.atlassian.jira.plugin.webfragment.model.JiraHelper;
import com.atlassian.jira.testkit.client.Backdoor;
import com.atlassian.jira.testkit.client.JIRAEnvironmentData;
import com.atlassian.jira.testkit.client.util.TestKitLocalEnvironmentData;
import com.atlassian.jira.user.ApplicationUser;
import com.atlassian.jira.user.UserProjectHistoryManager;
import com.atlassian.jira.user.util.UserManager;

As the comment (above) says, you will have to create a few resources before this constructor can execute successfully.

src/test/resources/localtest.properties

jira.protocol = http
jira.host = localhost
jira.port = 2990
jira.context = /jira
jira.edition = all

jira.xml.data.location = ../../../test-classes/xml

src/test/resources/xml/.keepme

This file is empty – it merely ensures that the xml directory is committed to source code control.

src/test/resources/atlassian-plugin.xml

The plugin-tests plugin now requires more import-packages than its parent plugin. So add the following section to the plugin-info statement:

<bundle-instructions>
    <Import-Package>
        com.atlassian.jira.plugin.webfragment.model;resolution:="optional",
        com.atlassian.jira.user.util;resolution:="optional",
        com.atlassian.jira.util.collect;resolution:="optional",
        com.atlassian.jira.util;resolution:="optional",
        org.springframework.osgi.*;resolution:="optional",
        org.eclipse.gemini.blueprint.*;resolution:="optional",
        *;version="0";resolution:="optional"
    </Import-Package>
</bundle-instructions>

At this point, the test should still be failing for the same reason as before (because the project is null, not because of an error thrown in the constructor).

You’re now equipped to initialise all the required bits and pieces to enable the test to pass. Add before and after functions for your tests like this:

@Before
public void setup() {
    deleteSampleData();
    /* final long projectId = */ backdoor.project().addProject(
            projectName, projectKey, userName, projectType);
    final Project project = ComponentAccessor.getProjectManager()
            .getProjectByCurrentKey(projectKey);
    userProjectHistoryManager.addProjectToHistory(applicationUser, project);
}

@After
public void cleanup() {
    // Comment out this line if you want sample data to remain in the system after the tests have run
    deleteSampleData();
}

private void deleteSampleData() {
    try {
        backdoor.project().deleteProject(projectKey);
    } catch (Throwable e) {
        // ignore
    }
}

The following imports are added:

import org.junit.After;
import org.junit.Before;

The test should now pass.

NB (don’t do this now, but note for future use): if you add a constructor argument of type MyPluginComponent as well, you can call its public methods to provide additional help with the setup and teardown functions. You can also use the ProjectManager instance returned by the ComponentAccessor to create and delete project categories, issue types and more, which the backdoor will then be able to add to projects. For example (assuming you have declared constant strings for categoryName, categoryDesc, testIssueType and testIssue):

final ProjectManager projectManager = ComponentAccessor.getProjectManager();
final ProjectCategory projectCategory = projectManager.createProjectCategory(categoryName, categoryDesc);
final long projectCategoryId = projectCategory.getId();
backdoor.project().setProjectCategory(projectId, projectCategoryId);
final IssueTypeControl.IssueType issueType = backdoor.issueType().createIssueType(testIssueType);
backdoor.issues().createIssue(projectKey, testIssue, userName, "2", testIssueType);

If you add issue types and project categories in the setup method, remember to remove them in the teardown method – or in this example, in deleteSampleData().

Previous Page | Next Page | Pages: 0 1 2 3 4 5 6 7

Comments (0)

×

Sign up for our Updates

Sign up now for our updates.

This field is required
This field is required
This field is required

I'm interested in:

Select at least one category
You were signed up successfully.

Receive regular updates from our blog

Subscribe

Or would you like to discuss a potential project with us? Contact us »