Yes, I think "Refactor" should be an explicit step. Otherwise it is ignored too often.
I'm also not the biggest fan of the popular "Red - Green - Refactor" cycle. Mainly, because it is missing another important explicit step. Kent Beck originally wrote the following in his famous book:
Add a little test
Watch it fail
Make a little change
Run Tests and succeed
Refactor to remove duplication
The second step is super important and I am happy that Hannah mentioned it in this post. Watching the test fail should be an explicit step in every TDD cycle as well.
This is interesting because I was debating about specifying about the "Red - Green - Refactor" in the article. However, I felt that it narrowed down the essence of TDD. If someone is new to the concept, I don't want them to think this is the main or 'only' way.
I really like the Kent Beck reference. Which book is this from? I'm interested in reading it.
I was thinking about the same thing, in the beginning i was coding with TDD i was always telling to myself the different steps (like in the image) i was like red, green, purple, red green, purple... my coworkers thought i was crazy (well they're not wrong xD) I like that sentence in your article "help teams communicate the intentions of their code's" it is true, sometimes i write a test for "documentary" purpose but don't forget refactoring can help your team to understand your code :)
Thanks for sharing the article, the image is very concise.
I can relate to the thinking of steps in colors, having an art background a lot of the way I code is very visual in my mind.
Hi Hannah,
Hi Andy,
Yes, I think "Refactor" should be an explicit step. Otherwise it is ignored too often.
I'm also not the biggest fan of the popular "Red - Green - Refactor" cycle. Mainly, because it is missing another important explicit step. Kent Beck originally wrote the following in his famous book:
The second step is super important and I am happy that Hannah mentioned it in this post. Watching the test fail should be an explicit step in every TDD cycle as well.
This is interesting because I was debating about specifying about the "Red - Green - Refactor" in the article. However, I felt that it narrowed down the essence of TDD. If someone is new to the concept, I don't want them to think this is the main or 'only' way.
I really like the Kent Beck reference. Which book is this from? I'm interested in reading it.
It's from Test-Driven Development By Example.
The book is absolutely worth reading. And with its 240 pages, it is relatively short. :-)
I was thinking about the same thing, in the beginning i was coding with TDD i was always telling to myself the different steps (like in the image) i was like red, green, purple, red green, purple... my coworkers thought i was crazy (well they're not wrong xD) I like that sentence in your article "help teams communicate the intentions of their code's" it is true, sometimes i write a test for "documentary" purpose but don't forget refactoring can help your team to understand your code :)
overall nice article though :)
(image found on google: "test driven development circle" found it from the site lewandowski.io/2017/02/thre-levels...
Thanks for sharing the article, the image is very concise.
I can relate to the thinking of steps in colors, having an art background a lot of the way I code is very visual in my mind.
you're welcome ! :D I'm more a "talk-to-myself" kind of person and moving a lot in the office it .... can annoy some colleagues xD
I even used to push the failing test, to have the CI prove I have a test I can make run.