###Definitely, not in a single file.

We are using Protractor as well and have a large test codebase and I think, we've learned a lot of lessons along the way. What is working for us are the following principles:

• use Page Object pattern to abstract away the elements and blocks of a page building a convenient API for your tests to use

• put page objects to under po directory, specs to under specs organized using inner directories per screen or per feature. Here is our current directory structure:

   /config
   /helpers  (a collection of helper methods and internal testing utilities)
   /po
       /dashboard.po
           index.js
           filters.po.js
       profile.po.js
   /specs
       /dashboard
           /validation
           defaultView.spec.js
       /exportToExcel
           ...   
  

Note how we are defining some page objects as "node packages" in directories with index.js and "child" page objects. We are also using requirePO and requireHelper functions to ease importing page objects and helpers inside tests, suggested here.

• follow Protractor's Style Guide
• one test file should cover one particular block of functionality - it should be easy to set the describe description in one sentence without using "and" ("and" is usually a sign that you are trying to test two or more different things)
• aim to one assertion per test - this is not always achievable and does not always make sense, but most of the times this helps to avoid testing too many things in a single test
• if you are nesting describe blocks into each other - this is a strong sign of over-complicating this particular test. See if you are better off creating separate test files. "Flat is better than nested." (from the "Zen of Python")
• we also had success in using jasmine-data-provider that allows to "multiply" and parameterize tests
• enforce Style Guide and other rules with static code analysis (we've been using ESLint, eslint-plugin-jasmine and eslint-plugin-protractor plugins)
• group tests into logical groups with suites

###Definitely, not in a single file.

It does not scale. Putting tests into a single growing file hurts readability, becomes inconvenient to navigate through and prevents you you from seeing a bigger picture. Remember that the Code is much more often read than written.

We are using Protractor as well and have a large test codebase and I think, we've learned a lot of lessons along the way. What is working for us are the following principles:

• use Page Object pattern to abstract away the elements and blocks of a page building a convenient API for your tests to use

• put page objects to under po directory, specs to under specs organized using inner directories per screen or per feature. Here is our current directory structure:

   /config
   /helpers  (a collection of helper methods and internal testing utilities)
   /po
       /dashboard.po
           index.js
           filters.po.js
       profile.po.js
   /specs
       /dashboard
           /validation
           defaultView.spec.js
       /exportToExcel
           ...   
  

Note how we are defining some page objects as "node packages" in directories with index.js and "child" page objects. We are also using requirePO and requireHelper functions to ease importing page objects and helpers inside tests, suggested here.

• follow Protractor's Style Guide
• one test file should cover one particular block of functionality - it should be easy to set the describe description in one sentence without using "and" ("and" is usually a sign that you are trying to test two or more different things)
• aim to one assertion per test - this is not always achievable and does not always make sense, but most of the times this helps to avoid testing too many things in a single test
• if you are nesting describe blocks into each other - this is a strong sign of over-complicating this particular test. See if you are better off creating separate test files. "Flat is better than nested." (from the "Zen of Python")
• we also had success in using jasmine-data-provider that allows to "multiply" and parameterize tests
• enforce Style Guide and other rules with static code analysis (we've been using ESLint, eslint-plugin-jasmine and eslint-plugin-protractor plugins)
• group tests into logical groups with suites

Definitely, not a in a single file.

We are using Protractor as well and have a large test codebase. What is working for us are the following principles:

• use Page Object pattern to abstract away the elements and blocks of a page building a convenient API for your tests to use

• put page objects to under po directory, specs to under specs organized using inner directories per screen or per feature. Here is our current directory structure:

   /config
   /helpers  (a collection of helper methods and internal testing utilities)
   /po
       /dashboard.po
           index.js
           filters.po.js
       profile.po.js
   /specs
       /dashboard
           /validation
           defaultView.spec.js
       /exportToExcel
           ...   
  

Note how we are defining some page objects as "node packages" in directories with index.js and "child" page objects

• follow Protractor's Style Guide
• one test file should cover one particular block of functionality - it should be easy to set the describe description in one sentence without using "and" ("and" is usually a sign that you are trying to test two or more different things)
• aim to one assertion per test - this is not always achievable and does not always make sense, but most of the times this helps to avoid testing too many things in a single test
• we also had success in using jasmine-data-provider that allows to "multiply" and parameterize tests
• enforce Style Guide and other rules with static code analysis (we've been using ESLint, eslint-plugin-jasmine and eslint-plugin-protractor plugins)
• group tests into logical groups with suites

###Definitely, not in a single file.

We are using Protractor as well and have a large test codebase and I think, we've learned a lot of lessons along the way. What is working for us are the following principles:

• use Page Object pattern to abstract away the elements and blocks of a page building a convenient API for your tests to use

• put page objects to under po directory, specs to under specs organized using inner directories per screen or per feature. Here is our current directory structure:

   /config
   /helpers  (a collection of helper methods and internal testing utilities)
   /po
       /dashboard.po
           index.js
           filters.po.js
       profile.po.js
   /specs
       /dashboard
           /validation
           defaultView.spec.js
       /exportToExcel
           ...   
  

Note how we are defining some page objects as "node packages" in directories with index.js and "child" page objects. We are also using requirePO and requireHelper functions to ease importing page objects and helpers inside tests, suggested here.

• follow Protractor's Style Guide
• one test file should cover one particular block of functionality - it should be easy to set the describe description in one sentence without using "and" ("and" is usually a sign that you are trying to test two or more different things)
• aim to one assertion per test - this is not always achievable and does not always make sense, but most of the times this helps to avoid testing too many things in a single test
• if you are nesting describe blocks into each other - this is a strong sign of over-complicating this particular test. See if you are better off creating separate test files. "Flat is better than nested." (from the "Zen of Python")
• we also had success in using jasmine-data-provider that allows to "multiply" and parameterize tests
• enforce Style Guide and other rules with static code analysis (we've been using ESLint, eslint-plugin-jasmine and eslint-plugin-protractor plugins)
• group tests into logical groups with suites