Looking for protractor best practices of sorts, is there any recommended 'average' length or size of an individual end to end test?

Our platforms features are all highly dependent upon on another so writing one off, short tests are proving to be difficult. The plan is to write as many scripts as needed and run them in parallel so length shouldn't matter.

1 Answer 1


I don't think there is a specific recommended test length threshold, but here are some of the things we've taken into account:

  • measure code complexity of your tests and specify practical thresholds (we use grunt-complexity)
  • enforce one top-level describe per file - this helps to avoid having multiple tests inside a single file
  • group test specs by a "feature" or "screen" into directories
  • try to have a single expect per it() block - one assertion per test
  • use Page Object pattern
  • follow the DRY principle - moving common repeated code into global "helpers" module
  • use using from the jasmine-data-provider to "multiply" tests
  • use custom jasmine matchers if a specific multi-step check is repeated and would benefit from being extracted into a jasmine matcher - for instance, we have a toBeActive() jasmine matcher that verifies that an element is in focus
  • use ESLint static code analysis tool with the relevant eslint-plugin-jasmine and eslint-plugin-protractor plugins to enforce best-practices

Some of the current stats from our protractor test codebase:

  • total specs: 239
  • the smallest spec: 12 lines
  • the largest spec: 242 lines
  • average spec: 66 lines
  • What I am doing is creating different test.spec.js files. Inside of those spec files, I am running through numerous describe and it blocks. The test.spec.js file is in its own suite, which in hindsight now, doesn't make a difference. In any case, I'm compiling the tests in one large spec.js file which sounds like it may not be a great idea based off of your recommendations. I plan (at some point) to create more re-usable code but at this point need to get full tests running soon. Should I scrap what I have and start over with smaller individual spec files in different suites?
    – kylokyler
    Jul 10, 2017 at 17:53
  • @Kelsey gotcha. The good news is that you've already started with the tests. I would probably start slowly, move things, describe by describe into separate specs trying to keep things organized by "feature" or "screen". Try to avoid test coupling - when the test execution order affects test results. I've also added some stats from our codebase. Hope that helps.
    – alecxe
    Jul 10, 2017 at 17:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.