search

xolvio / qualityfaster

An example project showing how to create robust and maintainable acceptance tests
262 stars 58 forks source link

How to test functionality that should only run through UI layer? #10

Closed danimbrogno closed 8 years ago

danimbrogno commented 8 years ago

Thanks for this great resource, I've learned a lot about domain driven design through this example and the links you provided. I have a question though.

There are aspects of my app which require a UI test, but do not require a domain level test and I'm not sure how this is best achieved.

For example, if a user wants to change their password. It doesn't make sense for me to test Meteor's built in password changing mechanism, but I would like to make sure that my app calls this method correctly.

Is there a way to mark a test to run on critical, and skip otherwise?

samhatoum commented 8 years ago

Technically, I guess you could configure that @no-domain or @critical-only tags are ignored in the domain run and not in the critical run. You can do this by overriding the tags for the domain run like this:

In the chimpSwitches 

chimp --tags="~@ignore,~@critical-only" watchTags="@dev,@watch,@focus,~@critical-only"

(untested)

I would recommend however that since there is no domain to discover and automate, that you instead write a good component unit test that validates you are integrating with the Meteor password mechanism, and then to trust that the Meteor portion will do its job. These will run at very high speed and the specification will be stored in the describe and it blocks

danimbrogno commented 8 years ago

Good points. Thanks!