Workflow Step by Step - MikeAndrianov/easy_learning GitHub Wiki

1. Go to Issues page
2. Select task
3. Discuss with other team members

###Code

1. Rspec first
2. Refactoring ( 50% of time )
3. DRY
4. Reuse the code
5. Commenting & Documentation
6. Indentation
7. Naming Scheme
8. Limit Line Length
9. Separation of Code and Data
10. Iteratively write code & specs - until the feature is finished
11. Fix any tests that have failed after your feature
12. We're following the same style guide as Github Ruby Style Guide does.

###Comments Put comments to ALL classes/modules, to any non trivial or complicated methods. Leave one separate commented line between comments and a definition, so the text is separated from the code and the link is maintained

for a module or a class

# Declares smth...
#
class / module ClassOrModuleName

for a methods within a module or class

# Returns smth...
#
def method_name

1. Create new branch from MASTER branch
2. Use branch names g<Issue number>_<FIO>__<task description>
3. More about Git workflow

###Commiting policy

• Should contain logically linked changes
• Message should be descriptive
• Do not do very large commits
• Use auto descriptors

###How to commit

1. Create a commit with description of what has changed from the previous state
2. Create new pull request
3. Ask team members to review your pull request
4. Resolve any questions that may appear

http://betterspecs.org/

• guard for testing automation
• spork for quicker testing
• rspec + cucumber

• If you are removing the functionality - you should remove the spec / or test that this functionality no longer available
• If you are not clear about how to implement the spec - leave it "defines your custom case" without block
• If test is failing - it should be fixed

test suit should always pass.

• Use: context {}, specify {}, it {}, subject {}, describe {}
• Start context with ‘when’/'with’ and methods description with ‘#’ context "when logged in"
• Use RSpec matchers to get meaningful messages specify { user.should be_valid } -is better then == true
• Only one expectation per it block
• Test Valid, Edge and Invalid cases
• Use let for eager loading

1. First #describe what you are doing
2. Then establish the #context
3. #it only expects one thing
4. Run specs to confirm readability
5. Use the right matcher
6. Formatting - used do end blocks