4 ms·

I wonder why no one has not mentioned tests. For me, the tests are more valuable for system or service understanding than, for example, documentation. But the b

I wonder why no one has not mentioned tests. For me, the tests are more valuable for system or service understanding than, for example, documentation. But the best scenario when you combine tests and documentation. I have joined the new team recently. They have a lot of e2e BDD tests implemented using the Cucumber framework. It helps me to get a complete view of the system in the shortest possible time.

stack_underflow 6y ago
Somewhat related; I've always been very curious why a lot of developers I've worked with seem to think testing isn't worth the effort, and I've been keeping a mental checklist of all the reasons/excuses I hear so that I can reflect on them as well against my own experiences - sort of a way to challenge myself and ensure I'm not just cargo-culting methodologies. Recently I decided to go through `Growing Object-Oriented Software - Freeman, Pryce` (and actually finish working through it this time) with the goal of understanding what "proper TDD" is supposed to look like. Something interesting I noticed is almost all the complaints I've seen as reasons against TDD/certain testing methods all seem to be examples the authors use as how not to use TDD/testing. It seems to me that a lot of developers have just learned _of_ these techniques by name, and haven't really put a lot of time/effort into practicing their application and instead just seem to write them off on face value or by the literal interpretation of their names. One example, a lot of people I speak with seem to think TDD is very literal "write a _unit-test_* for everything before you write the implementation OR ELSE...", but of course there's a lot more nuance than that depending on the situation. The book actually puts a huge emphasis on having your initial test(s) be end-to-end tests that slice through the system as a whole, with the idea being to create nested feedback loops of varying granularity/abstraction to allow you to iterate without fear. This was something I never heard emphasized at all when I started learning about TDD, or hell even in a paid course my employer put us through by a "TDD expert". I should also clarify, I only consider these claims from developers that have a proven track record of working on large/complex systems since, well, those who don't probably haven't cultivated their ideal workflows/approaches yet (or just haven't been given the opportunity to showcase them, as is common in large companies). * I emphasize unit-test because a lot of code bases I've worked in rarely have anything other than just unit-tests...
- vendiddy 6y ago
  I agree. Everyone should consider the costs and benefits of testing to arrive at a system that works for them. Early on in a system design, I prefer going overboard with integration tests. The architecture is hard to predict early on, so I don't want to get paralyzed on figuring it out. Just get the tests passing without overthinking. Once I find a better way to do things, I can rip apart and restructure the internals with the safety net of end to end tests. I rarely write unit tests at this stage because the effort of writing and rewriting them adds friction to getting the software working and restructuring the code. If every time I redraw a boundary, I need to rewrite a bunch of unit tests, I'll be less likely to improve the code quality.
sethd 6y ago
Completely agree. Tests/specs are the best way to learn a system. The article barely even mentions tests and the scenario they describe revolves around the use verifying correctness when making your first change to the codebase. Not a thing about using them to understand the behavior of the SUT.
williamdclt 6y ago
I'm skeptical that you get a view of the system through BDD tests better than with somebody walking you through the product. The person can explain the domain, the context, the subtleties, skip the not-actually-interesting-parts, draw things for visualisation, etc while adapting the explanations to the fact that they're talking to a newcomer: the tests do none of that (but maybe I've never done BDD properly)

stack_underflow 6y ago

Somewhat related; I've always been very curious why a lot of developers I've worked with seem to think testing isn't worth the effort, and I've been keeping a mental checklist of all the reasons/excuses I hear so that I can reflect on them as well against my own experiences - sort of a way to challenge myself and ensure I'm not just cargo-culting methodologies. Recently I decided to go through `Growing Object-Oriented Software - Freeman, Pryce` (and actually finish working through it this time) with the goal of understanding what "proper TDD" is supposed to look like. Something interesting I noticed is almost all the complaints I've seen as reasons against TDD/certain testing methods all seem to be examples the authors use as how not to use TDD/testing. It seems to me that a lot of developers have just learned _of_ these techniques by name, and haven't really put a lot of time/effort into practicing their application and instead just seem to write them off on face value or by the literal interpretation of their names. One example, a lot of people I speak with seem to think TDD is very literal "write a _unit-test_* for everything before you write the implementation OR ELSE...", but of course there's a lot more nuance than that depending on the situation. The book actually puts a huge emphasis on having your initial test(s) be end-to-end tests that slice through the system as a whole, with the idea being to create nested feedback loops of varying granularity/abstraction to allow you to iterate without fear. This was something I never heard emphasized at all when I started learning about TDD, or hell even in a paid course my employer put us through by a "TDD expert". I should also clarify, I only consider these claims from developers that have a proven track record of working on large/complex systems since, well, those who don't probably haven't cultivated their ideal workflows/approaches yet (or just haven't been given the opportunity to showcase them, as is common in large companies). * I emphasize unit-test because a lot of code bases I've worked in rarely have anything other than just unit-tests...

vendiddy 6y ago
I agree. Everyone should consider the costs and benefits of testing to arrive at a system that works for them. Early on in a system design, I prefer going overboard with integration tests. The architecture is hard to predict early on, so I don't want to get paralyzed on figuring it out. Just get the tests passing without overthinking. Once I find a better way to do things, I can rip apart and restructure the internals with the safety net of end to end tests. I rarely write unit tests at this stage because the effort of writing and rewriting them adds friction to getting the software working and restructuring the code. If every time I redraw a boundary, I need to rewrite a bunch of unit tests, I'll be less likely to improve the code quality.

sethd 6y ago

Completely agree. Tests/specs are the best way to learn a system. The article barely even mentions tests and the scenario they describe revolves around the use verifying correctness when making your first change to the codebase. Not a thing about using them to understand the behavior of the SUT.

williamdclt 6y ago

I'm skeptical that you get a view of the system through BDD tests better than with somebody walking you through the product. The person can explain the domain, the context, the subtleties, skip the not-actually-interesting-parts, draw things for visualisation, etc while adapting the explanations to the fact that they're talking to a newcomer: the tests do none of that (but maybe I've never done BDD properly)