@Phillip Hallstrom: in the scope of the iterator, article will be passed in and you won't see an article you've exposed via the controller. This is probably fine though, because you're not likely to need to deal with the exposed article inside that iterator.
As to differentiating, the same could be said of methods in models.. "How do I know if it's a method or a variable?!" I can only say that it gets easier with time and is made even easier by tools integrating things like (exuberant) Ctags.
The simple fact of the matter is that instance variables are meant to be referenced internally by an instance of a class. Outside objects (like an instance of ActionView) having direct access to another object's internal state is an excellent way to increase coupling and doesn't abide by OO best practices like "programming to an interface".
This approach was guided largely by my attempt to adhere to OO design advice offered by tomes written by people much smarter than myself, such as the GoF's Design Patterns book.
@MissingHandle it's a delicate balance, but I find myself doing things like this:
Given the following users:
| first name | Chucky |
| last name | Myers |
When I am viewing the user index
Then I should see "Chucky Myers" in the "Users" section
Where 'in the "Users" section' is a way of scoping to a portion of the page (you can see our scoping steps in this gist: https://gist.github.com/894947)... This helps us only couple to the things that we need to see on the page in order to make effective assertions.
Again, it's a delicate balance that's more art (peppered with science) than anything.
@moabite, @tomrossi - I've stopped testing things via assigns entirely and check for the specific things I expect to see in the UI via integration tests (by interrogating request.body using a higher level encapsulation like RSpec/Capybara or Cucumber). For the most part I only use controller tests for unit testing 3rd party API integration or things I can't test via Selenium (like testing around Flash), and don't do any functional testing of my controllers.
@rbates thanks for the coverage! For more background on what motivated me to start using this pattern and subsequently encapsulate it as a gem, check out this post: http://blog.voxdolo.me/a-diatribe-on-maintaining-state.html
@moabite, we tend to use integration tests for that sort of thing at Hashrocket. Asserting against the content of an instance variable in your tests means you're coupling with a specific part of an implementation. Interrogating the UI for the presence of an expected element (likely the name of a user or users in this case), allows you to only assert things you care about.
@Phillip Hallstrom: in the scope of the iterator, article will be passed in and you won't see an article you've exposed via the controller. This is probably fine though, because you're not likely to need to deal with the exposed article inside that iterator.
As to differentiating, the same could be said of methods in models.. "How do I know if it's a method or a variable?!" I can only say that it gets easier with time and is made even easier by tools integrating things like (exuberant) Ctags.
The simple fact of the matter is that instance variables are meant to be referenced internally by an instance of a class. Outside objects (like an instance of ActionView) having direct access to another object's internal state is an excellent way to increase coupling and doesn't abide by OO best practices like "programming to an interface".
This approach was guided largely by my attempt to adhere to OO design advice offered by tomes written by people much smarter than myself, such as the GoF's Design Patterns book.
@MissingHandle it's a delicate balance, but I find myself doing things like this:
Given the following users:
| first name | Chucky |
| last name | Myers |
When I am viewing the user index
Then I should see "Chucky Myers" in the "Users" section
Where 'in the "Users" section' is a way of scoping to a portion of the page (you can see our scoping steps in this gist: https://gist.github.com/894947)... This helps us only couple to the things that we need to see on the page in order to make effective assertions.
Again, it's a delicate balance that's more art (peppered with science) than anything.
@moabite, @tomrossi - I've stopped testing things via assigns entirely and check for the specific things I expect to see in the UI via integration tests (by interrogating request.body using a higher level encapsulation like RSpec/Capybara or Cucumber). For the most part I only use controller tests for unit testing 3rd party API integration or things I can't test via Selenium (like testing around Flash), and don't do any functional testing of my controllers.
@rbates thanks for the coverage! For more background on what motivated me to start using this pattern and subsequently encapsulate it as a gem, check out this post: http://blog.voxdolo.me/a-diatribe-on-maintaining-state.html
@moabite, we tend to use integration tests for that sort of thing at Hashrocket. Asserting against the content of an instance variable in your tests means you're coupling with a specific part of an implementation. Interrogating the UI for the presence of an expected element (likely the name of a user or users in this case), allows you to only assert things you care about.