What’s the best way to implement performance enhancements from
the outside-in? For example, if I’m working test-free and I know I’m
going
to be looking up my Shops by phone number often, I’ll write a migration
to
make phone_number an index of the shops table. What feature(s) and
spec(s)
would I write to drive me to that migration?
What’s the best way to implement performance enhancements from the outside-in?
For example, if I’m working test-free and I know I’m going to be looking up my
Shops by phone number often, I’ll write a migration to make phone_number an index
of the shops table. What feature(s) and spec(s) would I write to drive me to that
migration?
Cheers,
Shea Levy
I try to think of an example, from the user’s perspective, that
describes a goal I’m trying to meet.
So in the case of the shop, I might say:
Given there are 10,000 Shops in the system
When I look up a Shop by it's phone number
Then I should see the result within 0.2 seconds
Just as with business rules, forcing yourself to describe the goal in
such concrete terms can trigger some very interesting and useful
conversations.
Obviously you will find that these kinds of tests behave much less
deterministically than business rule tests, so it’s useful if you can
make your development and test environments as homogenous as possible.
You can also help smooth this out by making the scenario work with
averages instead:
Given there are 10,000 Shops in the system
When I perform 100 searches for a Shop by phone number
Then on average, I should see the result within 0.2 seconds
These sorts of tests are also much slower than business rule tests,
because they tend to need lots of data and to take several samples to
get their average. It’s worth tagging them to exclude them from your
check-in build run and running them in a nightly build instead.