###Consider the four responsibilities that Rebecca lists for client side code (hint: they're color coded).
- I'm not sure that it was surprising, but it was interesting to notice that when looking at the page itself and breaking out the actual display elements into those categories, that there wasn't any mention of testing the presentation side of things. We've been shown repeatedly that it is possible, but told to question whether that's really what we should be testing (ie test biz logic instead).
Do you feel like you mentally split your client side code in IdeaBox and other past projects into these responsibilities?
- I haven't specifically tried to break out testing into these responsibilities, but it's obvious Rails tries to push that kind of breakdown by using things like Model tests to strictly test Data and View tests to test Presentation. I could see Feature tests being viewed as a way to test that your Applications State is behaving how you expect it to. Even setup tests, the "glue", seem like they could be similar to Controller tests, expecting simple responses to ensure that basic connections exist. It may not be exact but this does seem to be a recurring theme in agile programming.
- After thinking about it a bit more, I feel like Integration tests feel more they're testing the glue and Controllers are testing state validity.
👍