I use TDD as a thinking tool in my development workflow. By doing this I can often avoid big up front design while driving towards the correct balance of abstraction. I always start by making it work, just puke the code in my brain on the screen, then make it pretty (reflect upon and refactor) my code to include any learning I may have discovered. I continue this process while pushing back against a tension of poor design / under abstraction until I can see concepts emerging.
I then collect these into methods and classes as I think about SOLID and Single Level of Abstraction during my reflect/refactor step of the TDD cycle.
This allows me to solve the problem at the micro-scale, thus rooting out the many assumptions I have when only solving in my mind or all at once. Our minds are horribly irrational and prone to biases, thus trying to problem solve at the macro-scale is an exercise in frustration and bugs.
By using TDD to slice the problem up, I am able to build context and grip the problem properly before I worry about the elegance of my solution.
Experience is a big factor in slicing the problem and applying TDD to guide my thinking. I like to remind myself TDD is any developer written test. Be it unit, integration, BDD, learning, etc. They all help guide and document my understanding of the problem at the various levels of complexity in the given domain.
I never managed to do TDD. Even though I tried, it's just too hard for me.
I'm fine with testing but if you write your tests afterwards.
What I do however is, whenever I write an API (not a REST one), I start by writing on a paper how I want to use it. And then I figure out the internals.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Interesting. I'd add the notion of pain in the ass. Whenever I code something, I basically do the following:
(the more experienced you get the more you can do parts 1 to 4 in your head)
Then obviously, when some new feature comes in:
The main idea here: factorize/automate when it hurts.
I use TDD as a thinking tool in my development workflow. By doing this I can often avoid big up front design while driving towards the correct balance of abstraction. I always start by making it work, just puke the code in my brain on the screen, then make it pretty (reflect upon and refactor) my code to include any learning I may have discovered. I continue this process while pushing back against a tension of poor design / under abstraction until I can see concepts emerging.
I then collect these into methods and classes as I think about SOLID and Single Level of Abstraction during my reflect/refactor step of the TDD cycle.
This allows me to solve the problem at the micro-scale, thus rooting out the many assumptions I have when only solving in my mind or all at once. Our minds are horribly irrational and prone to biases, thus trying to problem solve at the macro-scale is an exercise in frustration and bugs.
By using TDD to slice the problem up, I am able to build context and grip the problem properly before I worry about the elegance of my solution.
Experience is a big factor in slicing the problem and applying TDD to guide my thinking. I like to remind myself TDD is any developer written test. Be it unit, integration, BDD, learning, etc. They all help guide and document my understanding of the problem at the various levels of complexity in the given domain.
I never managed to do TDD. Even though I tried, it's just too hard for me.
I'm fine with testing but if you write your tests afterwards.
What I do however is, whenever I write an API (not a REST one), I start by writing on a paper how I want to use it. And then I figure out the internals.