If you've spent much time in software development, you've undoubtedly heard the expression “test-driven development” or "TDD" for short.
The idea ...
For further actions, you may consider blocking this person and/or reporting abuse
Can i upvote this to make it a headline in every dev publication? Seriously impactful! I use literate programming myself, writing docs first and code along the way. Most people do before they think, well, do docs first then, the thinking goes in parallel. Better code will follow.
This is one of the kindest comments I've received on anything I've written - thank you.
Nice!! Just stumbled on GitHub star Monica Powell’s four-part series focusing on Document-Driven GROWTH, which is a nice complement. (This is part 4 but it’s the only one that links to all the others:) github.com/readme/guides/document-...
I will for sure have to check it out, Monica does great work!
Very cool article. DDD seems taken by Domain Driven Design. And perhaps that goes into a similar direction as this article.
I was actually already familiar with Domain Driven Design, but I couldn't think of an alternative term than "Documentation Driven Design" to clearly and quickly articulate my thoughts
you can take advantage of tsdoc or jsdoc.
You absolutely can, to be fair. Just another tool in the toolbox of documentation
Swagger can be a great tool to experiment with API design, especially when tied into hard coded data for a real API feel that you can incrementally build around and get feedback for!
Totally agree, I wish more teams would implement this approach
I'm sorry, i didn't agree at all. TDD is documentation and testing together. If you forget to update the test when a function changed, the tests will fail. Deprecated documentation does not fail. Once you have deprecated documentation you don't rely on it because you don't know which one is updated and which one didn't.
About the reading complexity of the test suites, you can try with BDD and gherkins.
A method in programming has to explain what it does within the function name.
You like to read, then after your mentions about TDD I think that you really don't know TDD. I recommend you reading first the: Test-Driven Development by Example (Kent Beck), from the mastermind of it.
Thank you !
Comments in code are just noise and they're practically never up to date. Unit tests are there to specifiy a behavior (business rules) you can easily use the tests as documentation. The truth (what the product actually does) is in the code not in the documentation, tests are there to be sure behavior didn't changed and act as documentation, i never trust documentation i only trust what i see in the code
Yes, completely agree. Documentation that is not automatically validated against the code for correctness is the worst kind imho. This is because over time it becomes outdated and paints a different picture of what the system is doing and how; and it will get outdated.
However imho the code + the tests, together, form a self validating single source of truth of documentation. The tests document what the system does and the code documents how it does it.
And they both keep each other honest.
Talk about reading, let's read too "Why are we yelling? : the art of productive disagreement" by Buster Benson.
Great article! As I say to TDD cultists when they advocate their propaganda, if you're using TDD to design your api, then you're starting on the wrong foot. The design should be worked out before any production code or tests are written, though I prefer the term Design Driven Development.
See, I'm not even convinced TDD is entirely on the wrong foot, especially when applied with nuance. Clean tests can serve an important role in providing documentation for behavior in code.
For me, it's when tests are seen as the ONLY form of planning or documentation for a codebase, or even consume a majority of time to take away from other forms of documentation that I find a problem.
Similarly types aren't a perfect form of docs, but can be of help. It's all about balancing what information you're providing new devs in different mediums to create a whole story
Hammock Driven Development with minutes.