Passing the first test

posted in: Standards, Testing | 0

In this article we will look at how to make the first test fail.

[A] We are here with Martin, who is a developer using Cleverstack and is currently learing to grow his code, guided by tests.

[A] Hi Martin.

[M] Hi Andre. It’s a pleasure to be here.

[A] We are interested in the part of the TDD process that follows the setup of the infrastructure. Let’s assume you have a one click deploy infrastructure and all you have to do as a developer, is to push to the project repo. At his point you are faced with a chooice… Write a failing test; or; Hack out a feature. What do you do?

[M] Well, this is the interesting part. With my background as a developer and the way that I’ve been taught to program, as with most other developers, my initial reaction is to hack out a feature. This is the step that by default makes the most sense to me, but when you first encounter the idea of growing software by tests, that paradigm gets shifted. At fist, the shift is small, but then, as you start realising and seeing the value of TDD the paradigm shift becomes massive and the old way of hacking out features becomes, well, less than ideal. So to the question, “What do you do?”, my answer now is different from my answer last week, and is different from my answer a few months ago. Now I’ll answer, writing a failing test, because my paradigm has gone to that place and it makes sense, even though I am by no means an expert at doing this yet.

[A] What kind of test suites do you have in CleverStack?

[M] The test suites present in CleverStack by default are the Mocha test suite on the backend for unit testing, and on the frontend side it has Karma for unit and integration testing and Protractor for end-to-end (edge-to-edge) testing.

[A] In which suite will you start with your first test?

[M]  I will start in the Protractor suite because it deals with the e2e tests, and to us, those are the most important tests, because it test the system externally and it gives us a measure of acceptability.

[A]  Yes. You mention acceptance tests. When we look at the diagram below, is that the outer loop you are referring to?

[M] In my mind acceptance tests that are grouped together make up the building blocks of end-to-end testing. e2e tests test the system as a user would and the results are acceptable if they pass and unacceptable if they fail. In terms of the diagram I am referring to the outer loop yes.

[A] What do you mean by: “acceptance tests that are grouped together make up the building blocks of end-to-end testing”, in your test suite are there ways to connect tests to each other, so that if one unit test fails, it will influence the result of an e2e test?

[M] What I’m saying is that acceptance tests are the pieces (the single assertions) that make up the final e2e test of a certain part of the system. If one of those pieces fail, then the entire e2e test for that part of the system fails. I don’t see acceptance tests as unit tests though. Acceptance tests and e2e tests are basically the same thing, just different words used to describe the same concept.

[A] OH, I see where I confuse the issue. I am still talking about “tests” and have not yet come to the role of “assertions”. Are “assertions” and “tests” the same thing in your Protractor Test Suite?

[M] No, assertions and tests are not the same thing. A single test may have one or more assertions that either causes that test to pass or fail, but it’s not the same thing. A test may say that there must be a button with a specific title on the screen and the result of pressing that button will be the home screen (this is single test), whereas there would be an assertion for the existence of the button, an assertion for the title of the button and an assertion to check if the redirect was performed correctly (3 assertions to make a single test pass).

[A] I think it will help us to see what your test suite report to you for a failing test with one failing assertion. Do you have such an example?

[M]

e2e: manage facility should have a facility status filter section with options other than all
   Message:
     Expected true to equal false.
   Stacktrace:
     Error: Expected true to equal false.
    at null.<anonymous> (/home/theocoria/Projects/wsims/wsims_lp_frontend/app/modules/facility/domain/test/e2e/manage_facility.test.js:18:24)

e2e: manage facility should have a facility type filter section with options other than all
   Message:
     Expected true to equal false.
   Stacktrace:
     Error: Expected true to equal false.
    at null.<anonymous> (/home/theocoria/Projects/wsims/wsims_lp_frontend/app/modules/facility/domain/test/e2e/manage_facility.test.js:22:24)

e2e: manage facility should have a district filter section with options other than all
   Message:
     Expected true to equal false.
   Stacktrace:
     Error: Expected true to equal false.
    at null.<anonymous> (/home/theocoria/Projects/wsims/wsims_lp_frontend/app/modules/facility/domain/test/e2e/manage_facility.test.js:26:24)

e2e: manage facility should have a search box
   Message:
     Expected true to equal false.
   Stacktrace:
     Error: Expected true to equal false.
    at null.<anonymous> (/home/theocoria/Projects/wsims/wsims_lp_frontend/app/modules/facility/domain/test/e2e/manage_facility.test.js:30:24)

e2e: manage facility should have a "add new facility" button
   Message:
     Expected true to equal false.
   Stacktrace:
     Error: Expected true to equal false.
    at null.<anonymous> (/home/theocoria/Projects/wsims/wsims_lp_frontend/app/modules/facility/domain/test/e2e/manage_facility.test.js:34:24)

[A] Thanks for that example. Now that is clear to me. Back to the Acceptance or e2e test. Can you show us what your first test looks like?

[M] With pleasure. Here you go:

describe( 'e2e: manage facility', function() {

    var ptor;
    beforeEach(function() {
        ptor = protractor.getInstance();
        ptor.ignoreSynchronization = true;
        ptor.get( '/facility/manage' );
    });

    it( 'should have a facility status filter section with options other than all', function() {
        expect( true ).toEqual( false );
    });

    it( 'should have a facility type filter section with options other than all', function() {
        expect( true ).toEqual( false );
    });

    it( 'should have a district filter section with options other than all', function() {
        expect( true ).toEqual( false );
    });

    it( 'should have a search box', function() {
        expect( true ).toEqual( false );
    });

    it( 'should have a "add new facility" button', function() {
        expect( true ).toEqual( false );
    });

});

The detail –

Screen Shot 2014-07-04 at 11.09.13 AM

 

 

 

 

 

Context –

Screen Shot 2014-07-04 at 11.08.49 AM

Leave a Reply