- Write test cases strictly to expose core functions and errors
- Your test cases guard your app from future changes
- Test cases also tells how your app works
- Think about how other codes will impact your code
- Test cases test on the coding's behavior, not implementation.
- Write code in the SIMPLEST way to satisfy the test cases
- No need to write un-necessary codes
- That's why test cases are written strictly
- Test cases guard all code changes and future enhancement
- Keep code lean and readable
- Keep off duplicated code
- Make code meaningful and sensible
- Think about reading your code 1 year later
- If you are using a gem, read up more on the gem to learn how to refactor better
- A good basic of ruby/rails will help you to refactor better
- build model & DB, test model (rspec with shoulda)
- build controller, test controller (rspec)
- build view, test feature (capybara)
- Upper level testing will not need lower level testing eg. controller test do not need to test model
- Build features first and then work your way down
- Good for unknown workflow
- Can be slightly confusing as you keep jumping to model, and then back to feature
- However, feature test (written first) will keep you on track on what's to be done
- Focus on creating a happy path first if it does not exist
- "Work on the stuff you know the least about so that you can learn the most earlier" ~ David Hussman
- General direction of app scoping is to keep to MVP so that decision can be made easily
- Documentation by test cases (Rspec can print out test cases nicely)
- README file is used for very specific technical issues
- That's why test cases are written to show how your app works
- Manual is not the same as documentation
- System should be intuitive so manual is not needed
- Important information to user should be exposed in interface and not in manual
- For complex system, user manual can be done
- Always look for a gem before you create the app yourself
- Especially for the common issues such as login, logging, reputation score, etc