How to reuse beforeEach/afterEach in Jasmine JS?

Question

When writing tests with JasmineJS I have many tests that have similar beforeEach/afterEach code.

Is there a way to implement an inheritance model using JasmineJS tes

Answer 1

If you want to do this for all your suites, you can register a beforeEach or afterEach function in the topSuite:

jasmine.getEnv().topSuite().beforeEach({fn: function() {
   //log in as admin
}});

If you only want to apply it on some suites, you can work with sub-suites:

describe("as_admin", function() {
  beforeEach(function() {
    //log in as admin
  });

  describe('Services Page',function() {...});
  describe('Administrators Page',function() {...});

}

Answer 2

Reference: (Pivotal Labs Blog:Davis W. Frank)

He describes collecting shared functionality in a function that is called with parameters for the different individual suites. Calling this function within each suite will execute the common setup/configuration.

As to splitting tests across files; the file with the shared function can either be included within each page with a <script> tag if the tests are browser based, or by a require(...) near the top if the tests are node based. You can then run the tests independently but using that shared setup which is defined only once.

Answer 3

I think this is partially examined in this blog post and also answered here but i'm adding an adapted answer for your example:

Reusable code:

function sharedSetup(startPage) {
    beforeEach(function() {
        login_as_admin();
        browser().navigateTo(startPage);
    });

    afterEach(function() {
        logout();
    });
};

How to use it:

describe('Services Page', function() {
    sharedSetup('/services');

    it('Some test for services page', function() {});
});

describe('Administrators Page', function() {
    sharedSetup('/administrators');

    it('Some test for administrators page', function() {});
});

Answer 4

Jasmine does allow you to put beforeEach and afterEach outside of a describe call. In this way you can have setup and teardown that is global for all of your specs. Your logout() call seems like it might be a good candidate for global teardown, and if all of your specs login as an admin, you could move that out to global scope as well.

For things that are used in some, but not all, specs, having a method like your login_as_admin() seems like the best way to consolidate that logic in one place.