Writing Use Cases that can map to Jasmine specs

ROUGH DRAFT IN PROGRESS --- NOT READY FOR COMMENTS OR REVIEW

We can use Jasmine syntax to help define our use cases.

This has two primary benefits:

1. Our use cases map directly to tests in a Jasmine script.

2. Requirements are documented in the tests, and are available under the Specifications page at any time. (No more lost documentation.)

The most important idea to take away from this blog post: every Jasmine test must be atomic, meaning that it must answer a yes/no or true/false question.

At first glance, many business requirements cannot be tested in an atomic manner.

Consider this business requirement:

"If the Loan State = 'CA' or 'AR', and the Investor Code = 2, then hide Investor field."

We cannot test this statement atomically due to the number of combinatorial possibilities that result from mixing 'or' and 'and' operators, but we could test the following statements atomically:

• • If the State = 'CA' and the Investor Code = 2, then hide Investor field

  • If the State = 'AR' and the Investor Code = 2, then hide the Investor field

  • If the State != 'CA' or 'AR', the display the Investor field

  • If the Investor Code != 2, then display the Investor field

The question is: how can we link the bullet point list to the original business use case such that 'natural language' requirements are documented and also broken down into their component boolean tests?

The answer:

Jasmine organizes tests with two components:

• • describe() - describe functions represent a group of tests, or a test suite. 

    • We can have nested describe() functions to represent sub-groups of tests

  • it() - it statements are expressions of intended behavior, and represent the actual tests being performed.

    • We cannot nest it() functions

In order to map our natural language requirement to a Jasmine testing structure, we could format the requirement in the following way:

• • "Requirement 1: If the Loan State = 'CA' or 'AR', and the Investor Code = 2, then hide Investor field."

    • "Requirement 1.1: If the State = 'CA' and the Investor Code = 2, then hide Investor field."

    • "Requirement 1.2: If the State = 'AR' and the Investor Code = 2, then hide the Investor field."

    • "Requirement 1.3: If the State != 'CA' or 'AR', the display the Investor field."

    • "Requirement 1.4: If the Investor Code != 2, then display the Investor field."

Given these requirements, a developer could immediately write up the following code, which would at least document the requirements on a web page, and stub out tests that need to be developed:

describe("Requirement 1: If the Loan State = 'CA' or 'AR', and the Investor Code = 2, then hide Investor field.", function () {

    it("1.1: If the State = 'CA' and the Investor Code = 2, then hide Investor field.", function () {

        //todo: add test code

    });

    it("1.2: If the State = 'AR' and the Investor Code = 2, then hide the Investor field.", function(){

        //todo: add test code

    });

    it("1.3: If the State != 'CA' or 'AR', the display the Investor field.", function(){

        //todo: add test code

    });

    it("1.4: If the Investor Code != 2, then display the Investor field.", function(){

        //todo: add test code

    });

})

This script will then render under the Design/Specifications tab, with reminders ('SPEC HAS NO EXPECTATIONS') to alert developers that tests need to be written:

Note that our describe() statement has been rendered in black to inform us that the 'natural language' requirement is comprised of several tests, and that each of our atomic tests is rendered in blue.

Also note the dots below the Jasmine icon. These represent the individual tests. Because none of these tests have passed or failed, they are rendered in yellow.

Once the tests are implemented, these dots will be rendered in either green to red, representing a pass or fail respectively.

Takeaways:

1. Jasmine syntax provides tools to break down 'natural language' requirements into testable boolean statements, documenting both for future reference.

2. Jasmine can be used to document requirements before tests are written, such that requirements are documented in a central location available to Business Units, Project Managers, and Developers simultaneously.