[HN Gopher] Verification-First Development
___________________________________________________________________
Verification-First Development
Author : vinipolicena
Score : 34 points
Date : 2025-03-18 17:26 UTC (5 hours ago)
(HTM) web link (buttondown.com)
(TXT) w3m dump (buttondown.com)
| simonw wrote:
| I'm all for splitting up the definitions of "test-first
| development" (TFD) and "test-driven development" (TDD), because I
| think for many forms of software development TFD is an anti-
| pattern that actively discourages people from writing tests.
|
| Unfortunately this article appears to want to treat TDD as a sub-
| set of TFD. I'd like to redefine TDD to mean "you bundle tests
| with your implementation when you commit to source control" -
| where it doesn't matter if you wrote the tests before or after
| the implementation.
|
| I write a lot of my tests after, often using snapshot testing. I
| get the key benefits of a robust test suite - protection against
| future changes introducing bugs that my test suite would have
| caught - but I don't go through the torment of trying to figure
| out how to test something that I've not yet even fully designed.
| bitwize wrote:
| TDD has always meant to write your tests first. Red, green,
| refactor. If you're not doing TFD, you're not doing TDD; you're
| just developing with tests. TDD is test- _driven_ precisely
| because all implementation code is written to make some failing
| test pass. Code not so written is by definition broken and does
| not make it into production. (If you need to try out an idea
| without writing tests first, that 's called a spike and it
| should be thrown away after proving what you set out to prove
| with it.)
| jghn wrote:
| GP did say that they wish to _redefine_ the TDD term. So yes,
| they would agree that what they 're proposing isn't currently
| what TDD implies.
|
| Although I'd like to think telling people that they should
| have tests requires an acronym in 2025.
| RossBencina wrote:
| > I'd like to redefine TDD [...] don't go through the torment
| of trying to figure out how to test something that I've not yet
| even fully designed.
|
| What? The whole point of TDD is that you design the thing _by
| writing the tests_. That 's why it's called Test _Driven_.
| simonw wrote:
| Then it's TDD that I have a problem with.
|
| My main challenge is that I don't know what to call the tests
| I write, or the process that I use. Calling them "tests" can
| be confused with manual testing. I usually call them
| "automated tests" but it's a mouthful and not a term I hear
| from other people.
| Jtsummers wrote:
| You call the tests you write tests. I'm not even sure how
| this is a question. Manual tests and automated tests are
| terms used in industry, but mostly to distinguish manual
| versus automated end-to-end or integration tests. And then
| the only time you'd use the terms is when you have both
| _and_ feel a need to distinguish them. Otherwise, just call
| them tests.
| simonw wrote:
| Yeah, maybe I'm over-thinking this. If I establish that
| on my projects "make sure to include tests" means
| automated tests I'll probably be OK.
| voiceofunreason wrote:
| https://tidyfirst.substack.com/p/canon-tdd isn't particularly
| new; Beck has been consistent about "write tests before the
| code, one test at a time" for about 25 years now.
|
| Same idea, different spelling: do you really think TDD should
| get credit for your good results, when you aren't actually
| shackling yourself to the practices that the thought leaders in
| that community promote?
| simonw wrote:
| I want to credit "writing automated tests" with the good
| results that I get from that practice. The problem is I need
| terminology that's widely used by other developers.
| vinipolicena wrote:
| Post in which simonw explains the "snapshot testing" approach:
| https://til.simonwillison.net/pytest/syrupy
| visarga wrote:
| It might be a good idea to try vf-vibe-coding
| darioush wrote:
| Actually I think we will be writing more of the verification
| coding and allowing the solution to be re-written as necessary
| by AI.
| tester756 wrote:
| There's even better approach for big companies with huge budgets
| that need to get products right:
|
| Get validation team as an addition to your own tests.
|
| You start with specification and both teams - dev and val start
| developing parallelly.
|
| They'll develop their own tests, then review your code with huge
| focus on finding bugs, security issues and so on.
| weinzierl wrote:
| This sounds a lot like the V-model.
| Jtsummers wrote:
| Pretty much. V-Model is often executed as a BDUF process, but
| the model translates well into iterative processes.
___________________________________________________________________
(page generated 2025-03-18 23:00 UTC)