Target e2e suite

[hboylan]

Hey all, I've found that it'd be nice to target a particular test suite with angular-cli.

Something like ng e2e auth instead of editing the angular-cli.json:

"e2e": {
    "protractor": {
      "config": "--suite auth config/protractor.conf.js"
    }
  }

Looks like it'd be pretty easy to pass the proper arguments to the e2e task

[chompy18]

Hi,

Any ideas when this will be implemented?
I have multiple scenarios that should run different suites and this fits the bill perfectly!

👍

[filipesilva]

I don't have an update on when this will be available, but if someone is interested in doing a PR I'll review it.

As a workaround, right now you should be able to do npm run e2e -- --suite auth as well.

[hboylan]

I'd really like to knock out this easy little feature (or any angular-cli development), but I'm having trouble with the typings in the angular-cli project.

My recent fork appears to be missing something because I get a lot of errors like:

• Cannot find module 'fs'
• Cannot find name 'require'
• Parameter 'file' implicitly has an 'any' type

[filipesilva]

@hboylan where do you get those errors? If it's in your editor, it might mean that it doesn't support Typescript 2.0. You should be able to ignore them though, it won't affect much.

[victornoel]

@filipesilva the -- workaround to pass extra parameters to protractor doesn't seem to work anymore, I guess because we switched from using the package.json scripts to using directly protractor as a library…

Any idea for another workaround or maybe introduce another way to pass extra parameters to protractors?

[filipesilva]

@victornoel there isn't a way to pass arbitrary parameters but as far as this issue is concerned now there is a way to pass suites:

ng e2e --specs ./e2e/app.e2e-spec.ts --specs ./e2e/another.e2e-spec.ts

[victornoel]

@filipesilva actually specs are not suites :) they are different concepts in protractor!
A suite is a set of specs configured in the protractor configuration.
So technically, this issue is not solved.

Unfortunately for me, my need was to pass an exclude option to protractor, which isn't solved via specs nor suites (I should create another issue for this).

[filipesilva]

You're absolutely right, and I was confusing the two.

[filipesilva]

Can you tell me more about your usecase? Is it that you need to exclude specs/suites sometimes only?

[victornoel]

@filipesilva here it is:

• I have a frontend with angular, a backend with java and some other networked resources exploited by the backend.
• my e2e tests are for the frontend and I run them with mocks to simulate the backend: in that case, all tests can be run as long as my mocks return what is expected.
• I also want to run the e2e tests with the real backend deployed but without the networked resources (a limitation of our CI and processing resources too): in that case, some of these tests should be disabled, i.e. those pertaining to frontend functionality that relies on the existence of the other networked resources.

I see two ways of solving this need:

• (current way): in the tests that do need the external resources, I add a keyword in the name and exclude all files containing this keyword when I run the e2e tests with the real backend
• I could define two suites, one for the e2e tests with backend (so without some of the tests) and one for the mocked frontend