at the beginning – Cover at least on important happy path – Unit test before writing any line of code – At least 75% percent code coverage – Reduce code CRAP-iness < 30 – Change Risk Anti-Patterns – Run unit and component tests often – Do not comment tests except for a very valid reason – Do not remove tests except for a very valid reason
software engineering, of merging all developer working copies with a shared mainline several times a day. It was first named and proposed by Grady Booch in his method,[1] who did not advocate integrating several times a day.” – wikipedia “Continues Integration represents a paradigm shift. Without continues integration , your software is broken until somebody proves it works, usually during a testing or integration stage.” –Continues devlivery “Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible.” – Martin fowler
tense integrations – Increase visibility which enables greater communication – Catch issues fast and nip them in the bud – Spend less time debugging and more time adding features – Proceed in the confidence you’re building on a solid foundation – Stop waiting to find out if your code’s going to work – Reduce integration problems allowing you to deliver software more rapidly
Commit test should not take more that 10 minutes – Team should stop their job if tests are broken to fix – Smoke tests should run – Functional tests should run upon successful commit – Functional tests should run in parallel (< 2 hrs) – Non-functional tests should run at this stage Environment should be same as production