3 ms·

> I don't think everything needs a comprehensive set of unit tests though. There's a difference in the tests of that era though. Around the xp times, unit test

> I don't think everything needs a comprehensive set of unit tests though. There's a difference in the tests of that era though. Around the xp times, unit tests were for unit of functionality, not per-method.

ffk 1y ago
I think a more accurate version of this is: unit tests were not only per-method but also per functionality. This was often called BDD (Behavior Driven Development), e.g. Ruby's cucumber. Your intuition here is correct though.
- viraptor 1y ago
  I disagree with the "not only". The idea in xp is to write the test first. http://www.extremeprogramming.org/rules/testfirst.html http://www.extremeprogramming.org/rules/testfirst.html You don't know how many methods/functions (if any) you're going to add to make it pass, so they're explicitly per-functionality.
caseyohara 1y ago
That’s not really true. “Unit tests are small tests, each one exercising a little piece of functionality. The units tested are usually individual methods, but sometimes clusters of methods or even whole objects.” Extreme Programming Explained: Embrace Change, 2nd Edition (2004) Kent Beck
- Izkata 1y ago
  That quote is saying the same thing as GP.
- viraptor 1y ago
  You're agreeing with me there. "each one exercising a little piece of functionality". In Beck's approach the tests are added at each step for a simple functionality addition, which then gets implemented in the project to pass the test. These days unit tests are more commonly used as "every method is a unit to be tested completely", often after the implementation is already there.
  - caseyohara 1y ago
    I don’t see how? You said: “Around the xp times, unit tests were not per-method.” Beck said: “Unit tests are usually individual methods”
anonymars 1y ago
I also wonder if this is written from a statically-typed perspective. In dynamic-typing land there are so many more stupid little things that can break that the compiler would otherwise catch for you Either that or tracing/logging/debugging, but other than specific niches like parsing (of specific bug repros) I think integration tests are generally a lot more bang for the buck. Anyway, if you want to go down a related-but-unrelated rabbit hole, J.R. Thompson's lecture on the Space Shuttle Main Engines is a good one. You can probably watch it at higher speed to smooth out the many, many "uh"s (believe me, it's bad): Integrated testing: https://youtu.be/uow6v1EuybE?t=1292 https://youtu.be/uow6v1EuybE?t=1292 Test to failure: https://youtu.be/uow6v1EuybE?t=3135 https://youtu.be/uow6v1EuybE?t=3135 https://ocw.mit.edu/courses/16-885j-aircraft-systems-engineering-fall-2005/resources/lecture-6/ https://ocw.mit.edu/courses/16-885j-aircraft-systems-enginee... -- There's this more-modern link but in true modern fashion you can't really link to specific things presumably because it's all javascript muck: https://openlearninglibrary.mit.edu/courses/course-v1:MITx+16.885x+3T2019/course/#block-v1:MITx+16.885x+3T2019+type@sequential+block@c135b29c7bf84702b47182fbad8bf2d0 https://openlearninglibrary.mit.edu/courses/course-v1:MITx+1...

ffk 1y ago

I think a more accurate version of this is: unit tests were not only per-method but also per functionality. This was often called BDD (Behavior Driven Development), e.g. Ruby's cucumber. Your intuition here is correct though.

viraptor 1y ago
I disagree with the "not only". The idea in xp is to write the test first. http://www.extremeprogramming.org/rules/testfirst.html http://www.extremeprogramming.org/rules/testfirst.html You don't know how many methods/functions (if any) you're going to add to make it pass, so they're explicitly per-functionality.

caseyohara 1y ago

That’s not really true. “Unit tests are small tests, each one exercising a little piece of functionality. The units tested are usually individual methods, but sometimes clusters of methods or even whole objects.” Extreme Programming Explained: Embrace Change, 2nd Edition (2004) Kent Beck

Izkata 1y ago
That quote is saying the same thing as GP.
viraptor 1y ago
You're agreeing with me there. "each one exercising a little piece of functionality". In Beck's approach the tests are added at each step for a simple functionality addition, which then gets implemented in the project to pass the test. These days unit tests are more commonly used as "every method is a unit to be tested completely", often after the implementation is already there.
- caseyohara 1y ago
  I don’t see how? You said: “Around the xp times, unit tests were not per-method.” Beck said: “Unit tests are usually individual methods”

anonymars 1y ago

I also wonder if this is written from a statically-typed perspective. In dynamic-typing land there are so many more stupid little things that can break that the compiler would otherwise catch for you Either that or tracing/logging/debugging, but other than specific niches like parsing (of specific bug repros) I think integration tests are generally a lot more bang for the buck. Anyway, if you want to go down a related-but-unrelated rabbit hole, J.R. Thompson's lecture on the Space Shuttle Main Engines is a good one. You can probably watch it at higher speed to smooth out the many, many "uh"s (believe me, it's bad): Integrated testing: https://youtu.be/uow6v1EuybE?t=1292 https://youtu.be/uow6v1EuybE?t=1292 Test to failure: https://youtu.be/uow6v1EuybE?t=3135 https://youtu.be/uow6v1EuybE?t=3135 https://ocw.mit.edu/courses/16-885j-aircraft-systems-engineering-fall-2005/resources/lecture-6/ https://ocw.mit.edu/courses/16-885j-aircraft-systems-enginee... -- There's this more-modern link but in true modern fashion you can't really link to specific things presumably because it's all javascript muck: https://openlearninglibrary.mit.edu/courses/course-v1:MITx+16.885x+3T2019/course/#block-v1:MITx+16.885x+3T2019+type@sequential+block@c135b29c7bf84702b47182fbad8bf2d0 https://openlearninglibrary.mit.edu/courses/course-v1:MITx+1...