3 ms·

What do you mean never write any tests? The api should be the same. Order goes in, pizza comes out. The rest is implementation details that should not be expose

What do you mean never write any tests? The api should be the same. Order goes in, pizza comes out. The rest is implementation details that should not be exposed to a test.

raggi 3y ago
you're right, the api for ordering a pizza will probably stay the same. the cooking process won't though. stuffed crust? add some stuff in the middle. square? add some stuff in the middle. deep dish? add some stuff in the middle. iterate a while and your "one golden test" is what falls down.
- yCombLinks 3y ago
  Those items are all testable through the createPizza method. There should be lots of tests! You've made up the one golden test scenario as a strawman. Every scenario you listed changes the expected output(the pizza). If you are testing internal methods, your tests are going to tell you you have broken, even if the pizzas created are 100% correct. So people won't clean the code, because the tests break, and they don't know if they are actually broken.
  - raggi 3y ago
    every single comment extrapolating a trival example is a strawman
- jpc0 3y ago
  YAGNI Refactor when those things are needed, right now the cooking process is stick it in a warm over for x minutes. What are you testing there? The oven was preheated? Put in an assert, that doesn't need a test. That it stayed in for x minutes? You assuming the builtin sleep function is broken? Don't test library code, that's not your job. That the oven actually preheated correctly, that was discussed in the article, the oven and it's preheat method should be a dependency that gets passed in, again not needed to be tested here. Also in your example you are testing whether an if condition was evaluated as true. Give me an example of a stuffed crust pizza cooking process that has a unit test which cannot be checked by looking at the resulting pizza.
mrkeen 3y ago
> The rest is implementation details that should not be exposed to a test. But it's always implementation details all the way down! If `prepare` is not worth testing, why would `createPizza` be worth testing? `createPizza` is someone else's implementation detail.
- yCombLinks 3y ago
  The goal of this unit of code is to create a pizza from an order. There are no observable side affects. To verify the correctness of this unit of code, the only requirement is to map all inputs to outputs. Any assertions other than that mapping are not requirements to test correctness.
  - mrkeen 3y ago
    Yes, and I can create an even larger 'unit' of code around it, declare that it has 'no observable side effects', and claim that `createPizza` is just an implementation detail of that, and therefore needs no testing.
    - yCombLinks 3y ago
      Maybe? We don't know about the other code. Most code I work with would be sticking this output in a db or email or something, so any larger piece can't be isolated, so is no longer a single unit. It's about isolation from side affects, not how much code you can stick behind a single method call.

What do you mean never write any tests? The api should be the same. Order goes in, pizza comes out. The rest is implementation details that should not be exposed to a test.

raggi 3y ago

you're right, the api for ordering a pizza will probably stay the same. the cooking process won't though. stuffed crust? add some stuff in the middle. square? add some stuff in the middle. deep dish? add some stuff in the middle. iterate a while and your "one golden test" is what falls down.

yCombLinks 3y ago
Those items are all testable through the createPizza method. There should be lots of tests! You've made up the one golden test scenario as a strawman. Every scenario you listed changes the expected output(the pizza). If you are testing internal methods, your tests are going to tell you you have broken, even if the pizzas created are 100% correct. So people won't clean the code, because the tests break, and they don't know if they are actually broken.
- raggi 3y ago
  every single comment extrapolating a trival example is a strawman
jpc0 3y ago
YAGNI Refactor when those things are needed, right now the cooking process is stick it in a warm over for x minutes. What are you testing there? The oven was preheated? Put in an assert, that doesn't need a test. That it stayed in for x minutes? You assuming the builtin sleep function is broken? Don't test library code, that's not your job. That the oven actually preheated correctly, that was discussed in the article, the oven and it's preheat method should be a dependency that gets passed in, again not needed to be tested here. Also in your example you are testing whether an if condition was evaluated as true. Give me an example of a stuffed crust pizza cooking process that has a unit test which cannot be checked by looking at the resulting pizza.

mrkeen 3y ago

> The rest is implementation details that should not be exposed to a test. But it's always implementation details all the way down! If `prepare` is not worth testing, why would `createPizza` be worth testing? `createPizza` is someone else's implementation detail.

yCombLinks 3y ago
The goal of this unit of code is to create a pizza from an order. There are no observable side affects. To verify the correctness of this unit of code, the only requirement is to map all inputs to outputs. Any assertions other than that mapping are not requirements to test correctness.
- mrkeen 3y ago
  Yes, and I can create an even larger 'unit' of code around it, declare that it has 'no observable side effects', and claim that `createPizza` is just an implementation detail of that, and therefore needs no testing.
  - yCombLinks 3y ago
    Maybe? We don't know about the other code. Most code I work with would be sticking this output in a db or email or something, so any larger piece can't be isolated, so is no longer a single unit. It's about isolation from side affects, not how much code you can stick behind a single method call.