Difference between revisions of "Testing"
(New page: =General rule: practice test-first (TDD or BDD) development= ==Specific rule: write your code in such a way that it’s testable== Look, we all know we should spend the first three weeks...) |
(do automated builds) |
||
| (One intermediate revision by one other user not shown) | |||
| Line 1: | Line 1: | ||
| + | [[Category:Patterns]] | ||
| + | |||
=General rule: practice test-first (TDD or BDD) development= | =General rule: practice test-first (TDD or BDD) development= | ||
| Line 8: | Line 10: | ||
Writing tests is one of the easiest ways that a newbie can come along to a project and instantly contribute in a meaningful way. But if you’re constantly calling global variables, depending on live database connections and not providing a way to mock them up, or throwing fatal errors if every subsystem isn’t present no matter the context, then it’s going to be hard to write tests. So hard, in fact, that not only will you not do it, but neither will anyone else. | Writing tests is one of the easiest ways that a newbie can come along to a project and instantly contribute in a meaningful way. But if you’re constantly calling global variables, depending on live database connections and not providing a way to mock them up, or throwing fatal errors if every subsystem isn’t present no matter the context, then it’s going to be hard to write tests. So hard, in fact, that not only will you not do it, but neither will anyone else. | ||
| + | |||
| + | Having a test suite is essential to growing your developer code base beyond the 1 or 2 person small software development teams found in libraries. A test suite allows your software to grow collaboratively with confidence over time. An automated build application that pulls changes as they are checked in, and runs the test suite is an extremely helpeful safety net as development kicks into high gear. | ||
Latest revision as of 13:11, 10 February 2009
General rule: practice test-first (TDD or BDD) development
Specific rule: write your code in such a way that it’s testable
Look, we all know we should spend the first three weeks writing eight thousand tests to describe every corner of the code. And we all have bosses that will ask, every morning about 10:30am, “So, what do you have that you can show me?”
Not everyone is going to be able to write tests first. That’s not right, it’s not smart, but it’s the way the world works. But at least put in the hooks so someone else can come along and write tests.
Writing tests is one of the easiest ways that a newbie can come along to a project and instantly contribute in a meaningful way. But if you’re constantly calling global variables, depending on live database connections and not providing a way to mock them up, or throwing fatal errors if every subsystem isn’t present no matter the context, then it’s going to be hard to write tests. So hard, in fact, that not only will you not do it, but neither will anyone else.
Having a test suite is essential to growing your developer code base beyond the 1 or 2 person small software development teams found in libraries. A test suite allows your software to grow collaboratively with confidence over time. An automated build application that pulls changes as they are checked in, and runs the test suite is an extremely helpeful safety net as development kicks into high gear.
