A few minor issues I have

[caseyhoward]

Nevermind. I can't find out how to delete this. My replies to 4 and 6 are still valid but after watching Julie's presentation it's clear that my idea of unit tests is different from everyone else's.

Here's what I originally posted:
I just watched your presentation and thought it was good and I'm glad that someone has created a styleguide for protractor. I just wanted to mention a few things I don't quite agree with and see what other people think. One of the main problems I have is the implication that protractor is only for e2e tests. I also really like protractor for component (directive) integration tests. Some of these guidelines are very specific to the first case.

I like unit tests that don't rely on the DOM. Anything I need to test that relies on the DOM I prefer to use protractor. This makes the unit tests super fast and also provides a more thorough test of the integration with the browser and protractor. I caught a bug in protractor with on of these tests.

[Rule-01: Do not cheat on your tests]

It is suggested not to mock out anything. Some of my directives communicate with the server (through a service) and I like to stub this out. I don't want to have to run a server to integration test my directives. This also provides good documentation how the endpoints this directive talks to behave.

[Rule-04: Use one configuration file]

I like to use gulp, but I don't set up my configuration this way. I agree with what is said about not duplicating configuration. However, I like to be able to use protractor directly from the command line. This can be especially useful if I'm having a problem I believe is related to the tooling. I can rule out the gulp-protractor plugin right off the bat.

What I like to do is put the common configuration into its own file. Then, I create other files that use a require to pull it in and merge with the unique configuration. I assumed this was the reason the protractor configuration file is a ".js" file instead of a ".json" file.

[Rule-05: Group your e2e tests in a structure that makes sense to the structure of your project]

I completely agree with this for e2e tests. However, for component integration tests I like to put them within the directory of the component I am testing.

[Rule-06: Never use xpath]

I also agree with this 100% but not for the same reason. The main reason I don't use them is because CSS selectors exist and are ubiquitous to the web. Most web developers already know how to use them so there is nothing new to learn. For example, they are used by the DOM (e.g. document.querySelector).

I also think it would be very useful to provide an equivalent CSS selector to prove how much better it is. The only advantage I've ever found with xpath is that you can traverse back up to ancestors instead of only down the heirarchy.

That's about it. Thanks for creating this.

[CarmenPopoviciu]

I just watched your presentation and thought it was good and I'm glad that someone has created a
styleguide for protractor.

Thank you. I'm really happy to hear.

One of the main problems I have is the implication that protractor is only for e2e tests. I also really like > protractor for component (directive) integration tests. Some of these guidelines are very specific to the > first case.

You are right, the guidelines really focus on the first case, because that's where I saw most of the confusion and misunderstandings coming from. With directives opinions are quite divided, and even inside our team, we had a lot of discussions about what kind of tests we want for them. I think it ofc ultimately depends on how complex the directive is, but imo you can get away with testing most of the things in unit tests, as long as, as you pointed out, there's not excessive DOM testing going on.

It is suggested not to mock out anything. Some of my directives communicate with the server (through > a service) and I like to stub this out. I don't want to have to run a server to integration test my directives.

I updated that part this morning in the repo. I understand what you are saying and I think in the end it depends very much on your use case.

I like to use gulp, but I don't set up my configuration this way. I agree with what is said about not
duplicating configuration. However, I like to be able to use protractor directly from the command line.

You can still use protractor from the command line and just pass in some arguments. Not so elegant, but still doable.

Thanks for creating this.

Thank YOU very much for your thoughts and feedback. I really appreciate it ^_^