You can't write any code until you have first written a failing test.
Usually, when I am writing new code I try to define an interface before I write tests for it. I find that the tests start to fall out of it logically after the interface has been well-defined. I usually start with the question, "How do I want to invoke this task?" My metric is usually asking if a brand new developer with no knowledge of the project would be able understand what is happening from the interface alone. Basically, ensuring clean code.
You should delay design decisions until the blue phase
This is something I see devs doing commonly. Especially when they try to make the problem fit into a design pattern initially, rather than refactoring to the pattern. Don't start with any design. Refactor to the design when you have enough information to make valuable decisions about the design, given the domain and the context.
You should refactor tests too
I write code as clean as possible to make it self-documenting. I views tests in the same way. How do you use Object? Take a look at TestObject. It's that simple, so long as you keep your tests refactored. And you are right, they are also code. And if we use tests like documentation, then we need to treat them as such. The only thing worse than no documentation is documentation that's wrong. In the same way, a bad test is worse than no test at all. And an outdated test is a bad test.
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.
Great post!
Usually, when I am writing new code I try to define an interface before I write tests for it. I find that the tests start to fall out of it logically after the interface has been well-defined. I usually start with the question, "How do I want to invoke this task?" My metric is usually asking if a brand new developer with no knowledge of the project would be able understand what is happening from the interface alone. Basically, ensuring clean code.
This is something I see devs doing commonly. Especially when they try to make the problem fit into a design pattern initially, rather than refactoring to the pattern. Don't start with any design. Refactor to the design when you have enough information to make valuable decisions about the design, given the domain and the context.
I write code as clean as possible to make it self-documenting. I views tests in the same way. How do you use
Object? Take a look atTestObject. It's that simple, so long as you keep your tests refactored. And you are right, they are also code. And if we use tests like documentation, then we need to treat them as such. The only thing worse than no documentation is documentation that's wrong. In the same way, a bad test is worse than no test at all. And an outdated test is a bad test.