Aes/entity tests

I think it depends. If the UI is complex and you are afraid it will break,
then it may make sense to test this using the UI. Otherwise you can also
make a direct API call, bypassing the UI (or, if you can test the UI
without needing to use a @javascript browser, that's even better).

Your knowledge about the implementation comes into play as well. For
example, let's say you have a list of values that you show in the UI (say,
a list of states). If you paste the list of states directly into the
template, then it may make sense to write a test, to make sure the values
are correct. But if you put that list in a constant, and use that constant
in the template, and everywhere else, then you know the code is DRY and
that any changes will automatically be reflected in the UI (and maybe
expect that code review will detect a bad change to that constant).
Therefore, it may be unnecessary to test the UI in this case.

So this should also be an encouragement to keep your code nice and DRY. :)

On Fri, Jul 25, 2014 at 5:54 PM, Aaron Ellis Snyder <
notifications@github.com> wrote:

> In features/habit.feature:
>
> > +    Then there should be 1 public habit with the two users
> > +
> > +  Scenario: Converting public habit to private
> > +    Given a public habit
> > +    When the public habit is converted to private
> > +    Then there should be 1 private habit
> > +
> > +  Scenario: Converting private to public habit
> > +    Given a private habit
> > +    When the private habit is converted to public
> > +    Then there should be on pulic habit
> > +
> > +  Scenario: Converting shared to private habit
> > +    Given a shared habit
> > +    When the shared habit is converted to a private habit
> > +    Then there should be 1 public habit and 1 private habit
>
> Would this be a behavior test interacting with the UI?
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/mojotech/habit-api/pull/12/files#r15411525>.
>