There's a thing called zone pricing. Basically, it means that where you live decides what you pay. There are loads of examples. For instance, comparing myself (Netherlands, southern city) to somebody from the US (Miami, Florida).
They're both cities. Neither is the people hub of the country, both are not small. No prices were actually checked, but the basic idea is the main thing I'm trying to convey.
- Windows 7 costs him 199 dollars. Me it would cost 299 euros, which is about 350 dollars.
- A litre of fuel costs me 1.40 euros. A gallon of fuel costs him 2 dollars 50, or about 55 eurocents per litre.
- A big mac costs me 6 euros after tax. Him it would cost about 4 dollars (for a comparable burger).
- A DVD of a new movie costs him 20 dollars. For me it's impossible to acquire, and if I wait 5 months I could get that very same movie for 20 euros.
The difference between these three items is why I am really annoyed with the price of Windows (even though I'm certainly not going to buy it), I'm moderately miffed with the fuel and I'm quite OK with the burger.
Each of these items has a reason why it uses zone pricing.
The big mac is less expensive to make in the US due to local meat being cheaper. Also, if I wanted, I could just go to Miami and buy the US version of the burger at the US price. It cannot compete with the one at home since it spoils quicker than I can get it here.
The fuel is exactly the same price to produce, but I couldn't drive to the US to get cheaper fuel as it would completely obviate the point - I'd use more fuel to get it here than it would spare me.
Windows is the one that annoys me. It's the exact same product, no bit is different (other than IE being optional for its UI - which doesn't change anything, really). I could get one flown in for about 80 eurocents. Why do I have to pay about double to get it, then?
The movie is the worst of all. I can get it from there, cheaper than I could get it here if I wait for a few months, and there's no rational reason why I shouldn't be able to. I can buy the burger, I can buy the fuel, I can sort of buy Windows, but I can't buy (and use) the DVD? Why not, exactly? It won't spoil, the transportation cost isn't too high, I'm quite OK with everything being in English (which Hollywood productions tend to be in any case) so why can't I get it on the day that somebody somewhere can get it?
vrijdag 17 juli 2009
vrijdag 10 juli 2009
Classicist or Mockist TDD?
You can divide TDDers in two groups - Classicist and mockist TDDers.
The first will write unit tests that are somewhat dependant and that lead to tests that rely on other tests working. The order in this is not stored (usually) making the evaluation of a test run somewhat more complicated. The tests are pretty straightforward though, no awkward mocks have to be constructed and little duplicate code is required.
The second will write unit tests that are fully independant and that lead to tests that are very quick and reliable. The order of running tests is irrelevant and the result of a test run is exactly the code that is failing. The downside is that end-to-end testing falls away and that it results in much more code for the same result.
Most people either target one or the other. You either support mocks with lots of mock support that basically pretends to be functors in a similar-but-not-quite language that is usually badly designed and very limited test support that basically just says that there's a bunch of tests and that runs them in some random order. Classicist testing usually has a fully-featured testing framework with some order-specifying things and loads of long-time taking tests that scale ever less.
For either there are *loads* of options for C++. At least 8 mocking frameworks and 35 testing frameworks, no less.
The problem with this separation is that it's pretty stupid. Either option is bad when used as the sole answer to the question of testing. You're much better off using both, when they're at their best. Use mocks for the interconnecting classes that are fairly easy to test if you take out the bottom half, use regular testing for the classes that don't lend themselves to this. For some classical tests, replace the more unusable bottom-end classes with mocks and let the rest be.
None of those 35 testing frameworks targets getting a quickly failing test, or in fact the group of people that aren't on either extreme.
You can divide TDDers in two groups - but please don't.
The first will write unit tests that are somewhat dependant and that lead to tests that rely on other tests working. The order in this is not stored (usually) making the evaluation of a test run somewhat more complicated. The tests are pretty straightforward though, no awkward mocks have to be constructed and little duplicate code is required.
The second will write unit tests that are fully independant and that lead to tests that are very quick and reliable. The order of running tests is irrelevant and the result of a test run is exactly the code that is failing. The downside is that end-to-end testing falls away and that it results in much more code for the same result.
Most people either target one or the other. You either support mocks with lots of mock support that basically pretends to be functors in a similar-but-not-quite language that is usually badly designed and very limited test support that basically just says that there's a bunch of tests and that runs them in some random order. Classicist testing usually has a fully-featured testing framework with some order-specifying things and loads of long-time taking tests that scale ever less.
For either there are *loads* of options for C++. At least 8 mocking frameworks and 35 testing frameworks, no less.
The problem with this separation is that it's pretty stupid. Either option is bad when used as the sole answer to the question of testing. You're much better off using both, when they're at their best. Use mocks for the interconnecting classes that are fairly easy to test if you take out the bottom half, use regular testing for the classes that don't lend themselves to this. For some classical tests, replace the more unusable bottom-end classes with mocks and let the rest be.
None of those 35 testing frameworks targets getting a quickly failing test, or in fact the group of people that aren't on either extreme.
You can divide TDDers in two groups - but please don't.
Abonneren op:
Posts (Atom)
