DEV Community

Discussion on: Demonstrating TDD (Test-driven development) in Go

Collapse
 
individualit profile image
Artur Neumann

Agree about the less tests.
I could have tested one date at a time.
I would also argue I did refactoring. The first approach of the algorithm was to add 56 years. It did not worked, but not in all cases, so I made it smarter.
By now I found an other edge case where the algorithm does not work, so I will add a test and refactor the algorithm till it works correctly.
Or do you mean something else by "refactoring"

"But what's worse is that you're essentially writing code to a specification written by someone else."

I don't quite understand what the problem is with that. There is a requirement ans I try to solve it with the code.

Collapse
 
quii profile image
Chris James

Refactoring means changing the code without changing behaviour.

Every example you gave of refactoring there changed the way the system worked (so not refactoring)

This might help quii.dev/The_Tests_Talk

Thread Thread
 
individualit profile image
Artur Neumann

hmm OK, I see. But for that I first need some code that does work and where the tests pass. After the tests pass with my (ugly, not optimized, not perfect) code I can start refactoring in the sense of changing code without changing the behaviour.
Where in TDD does that step come?

Thread Thread
 
quii profile image
Chris James • Edited

From the link I sent you above

  • Write a small test for a small amount of desired behaviour
  • Check the test fails with a clear error (red)
  • Write the minimal amount of code to make the test pass (green)
  • Refactor
  • Repeat.

If you want a more involved tutorial read github.com/quii/learn-go-with-tests