26 Jan 2015
How to create a branch and checkout at the same time:
- Anything in the master branch is deployable
- To work on something new, create a descriptively named branch off of master (ie: new-oauth2-scopes)
- Commit to that branch locally and regularly push your work to the same named branch on the server
- When you need feedback or help, or you think the branch is ready for merging, open a pull request
- After someone else has reviewed and signed off on the feature, you can merge it into master
- Once it is merged and pushed to ‘master’, you can and should deploy immediately
Read more: A successful Git branching model
23 Jan 2015
- Add Rspec to your gemfile, make sure to include in both test and development:
group :test, :development do
gem 'rspec-rails'
end
- rails g rspec:install
Generates three items:
1. .rspec file - contains "color".. just means you want your output to be color-coded
2. spec folder
3. spec helper - where configuration goes
Create models folder inside spec folder
Create a todo_spec.rb within the models folder (name of model)
Within todo_spec.rb you must:
require 'spec_helper'
describe Todo do
it "saves itself" do
todo = Todo.new(name: "cook dinner", description: "love me some din din")
todo.save
Todo.first.name.should == "cook dinner"
end
end
** "it" is a keyword that begins each test
** "do" implements the test
** .should is another keyword will test to see if we have the desired result.
** == is the matcher
How to run rspec outside of Rails
- Create a project folder
- Inside the project folder, create a lib folder. Your code that you're testing will go inside here.
- Create another folder: spec, where your .spec test files will go.
- Make sure to require your code files inside your specs.
20 Jan 2015
There are 3 types of tests:
- Unit
- Functional
- Integration
Ranking according to:
Coverage:
Unit > Functional > Integration
Speed:
Unit > Functional > Integration
Realistic:
Integration > Functional > Unit
1) Unit Tests
- testing a component in isolation, focusing on 1 thing and making sure all cases are covered
- isolated components tested: routes, models, views, helpers
- allow you to thoroughly test all components.. as it is the closest to the code.
- is the fastest and gives you the best coverage
2) Functional Tests
- testing components in collaboration, making sure not only they work but that they play nicely with each other
- components tested: controllers (where everything interacts), typically once request/response cycle
3) Integration Tests
Builds upon functional tests in the sense that not only must play nicely together but they must achieve a desired business objective.
- Components tested: Goal is to emulate the user, typically occurs in browser and follows the entire business process and
that the business objective is achieved
There are multiple styles of testing.. it has become very much like an "art" as devs often times develop a taste of styles for what to test, when, etc. In this course, we will primarily write unit and functional tests leaving integration tests for important business workflows.
17 Jan 2015
A typically response to testing is "I don't have time, I have to meet my deadline"
As your project size increases, you technical debt increases to the nth degree as time passes.
The problem is that devs don't remember the code the wrote 3 months ago, so they have to do a "context switch"
and recall why they wrote the code they did. This often times can have a cascading effect of issues.
Rescue Projects:
That is why projects in this case are called rescue projects, bc they have to call in outside help to
fix their project. One of the first steps an outside company does to save rescue projects is create a test suite.
This is the pay off for the technical debt.
15 Jan 2015
Why Do we test our software?
Here, we are referring to automated testing:
What would be our alternatives:
Option 1. No tests at all:
this doesn't exist. This means that customers will do the testing for you. All software has bugs, so bugs encountered by your customers will make them aggravated and then you will lose them as customers, support costs will sky rocket
Option 2. Rely on QA Team - When we have a clear division b/w development
Typically for larger companies. Code is thrown over the wall to the QA team according feature scope or some other arbitrary milestone, for example.
* The QA Team writes design test cases according to code base and file bugs with the dev team.
* The code is authorized for release once everything is fixed.
This could create:
1. Organizational Trust Problems
communication b/w the teams typically is not very good. Including finger pointing, etc.
2. QA Team
- nobody likes them and they get blamed for everything. When everything works, devs take the credit
and when they don't work, the QA Team is blamed because their purpose is to catch things like that.
- Also, when deadlines, ship dates are missed, the dev team will often blame the QA Team for all the bugs or requirements
they have to work through. They complain that they don't have time to work on features bc of this.
- No one really aspires to be good "testers", typically its junior devs and there is a high-turnover bc no one typically wants to
stay there... therefore knowledge is lost.
- Release Cycles - typically both teams are competing for the same time bc each wants to a good job. This pushes back the deadlines.
Impact of having not automated tests
- Code quality - QA Team, developers, stakeholders, customers don't care as much
- Isolated Knowledge - only the developer can maintain that code, sometimes a form of job security
- How do you know the implemented feature works
- How do you know that things did not break as a result of this new feature - called regression problems