Testing_Conventions
- You should use the Rails URL and Path helpers instead of hard-coding them in your tests. (e.g. edit_plans_path(@plan) instead of '/plans/123/edit'
- You should use the I18n.t method to validate flash messaging rather than hard-coding messages in your tests
- You should include assertions that test both success and failure conditions
We realize that every developer has their own style and we encourage a bit of individuality. However, we do impose some of the following rules to contributions to this project.
-
We quite like the principle of DRY (Don't Repeat Yourself) so please always look through the existing code to make sure you are not reinventing something that has already been done. Also clever bits of code or reuse of existing ones to avoid copying and pasting is always appreciated.
-
Include database migrations when you are altering the database model. Use the following command to create a new migration and be specific about what it does in the name of the file
> rails g migration AddTwitterIdToUsers -
You do not need to comment every line of your code but we do expect to see inline comments explaining the intent of your if blocks and loops.
-
We do not want to see Tab characters. Tabs should be converted to a double space. If you are working on a file that has Tabs already, please convert them for us before making your Pull Request
-
If a line is going to go beyond 100 characters please break it out onto multiple lines. For example:
# This is preferable users = [{email: @user.email, password: 'bAd_pas$word1', remember_me: true}, {email: 'unknown@institution.org', password: 'password123', remember_me: true}] # to this long line that requires scrolling users = [{email: @user.email, password: 'bAd_pas$word1', remember_me: true}, {email: 'unknown@institution.org', password: 'password123', remember_me: true}]
-
Finally, please make sure your code is properly indented as this enhances readability.
 |
 |