Thank you, that at least clarified for me where the disconnect between our perspectives is: I don't see the tests as the point of truth, the specification and design documents are the points of truth that all code, test or otherwise, should follow.
Tech enthusiast studying ICT and graduating soon enough👨🏿🎓. Software Engineer in the making, experimenting my way through life. I'm here to connect, learn from y'all and share my knowledge.👊🏿
the specification and design documents are the points of truth that all code, test or otherwise, should follow.
You are totally right there and I agree with that. But what I mean is that the tests clarify that truth. For some, it is important to have the specification separated into bits and pieces that make it easier to tackle, for others they dive headfirst and hope for the best.
Tests are nothing without the specification, you need to know what you are building.
I don't know if I have a view on it as I don't think I really get the purpose of it. I've done it for a few projects and didn't see any inherent benefit from writing tests before the methods.
If I have a requirement to add two numbers, return zero if the first number is zero, and throw an error if the second number is less than zero, then I already know what code will be in the method and what functionality needs to be tested.
I could give those requirements to two different devs and have one write the test and the other write the implementation, give to one dev and have them write the test first and method second, or one dev writing the method first and the test second; in any of those cases the outcome is going to be the same, a test and a method that meet the specs.
Maybe it is a disconnect at the idea of what a specification is, but if you are having to refactor the method and the test a bunch, then it sounds like not enough prototyping was done in the first place to make a properly detailed spec.
If I have any point of view on TDD, it's that writing tests first seems like cargo cult fluff that overshadows the actual important message, that tests are vital and should be a fundamental part of development, regardless of them being written first, second, or last.
Tech enthusiast studying ICT and graduating soon enough👨🏿🎓. Software Engineer in the making, experimenting my way through life. I'm here to connect, learn from y'all and share my knowledge.👊🏿
that tests are vital and should be a fundamental part of development, regardless of them being written first, second, or last.
At least we can all agree on that part.😂 If you write it first or last, it is up to you and your team, but testing your code is important.
Maybe it is a disconnect at the idea of what a specification is, but if you are having to refactor the method and the test a bunch, then it sounds like not enough prototyping was done in the first place to make a properly detailed spec.
Can you elaborate a bit more on that part? If I understand you correctly, the specifications you are working with are super specific, almost like the tests you would be writing (thus, setting the assertion and expectations).🤔 I might be wrong there.
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.
Thank you, that at least clarified for me where the disconnect between our perspectives is: I don't see the tests as the point of truth, the specification and design documents are the points of truth that all code, test or otherwise, should follow.
You are totally right there and I agree with that. But what I mean is that the tests clarify that truth. For some, it is important to have the specification separated into bits and pieces that make it easier to tackle, for others they dive headfirst and hope for the best.
Tests are nothing without the specification, you need to know what you are building.
What is your point of view on TDD?
I don't know if I have a view on it as I don't think I really get the purpose of it. I've done it for a few projects and didn't see any inherent benefit from writing tests before the methods.
If I have a requirement to add two numbers, return zero if the first number is zero, and throw an error if the second number is less than zero, then I already know what code will be in the method and what functionality needs to be tested.
I could give those requirements to two different devs and have one write the test and the other write the implementation, give to one dev and have them write the test first and method second, or one dev writing the method first and the test second; in any of those cases the outcome is going to be the same, a test and a method that meet the specs.
Maybe it is a disconnect at the idea of what a specification is, but if you are having to refactor the method and the test a bunch, then it sounds like not enough prototyping was done in the first place to make a properly detailed spec.
If I have any point of view on TDD, it's that writing tests first seems like cargo cult fluff that overshadows the actual important message, that tests are vital and should be a fundamental part of development, regardless of them being written first, second, or last.
At least we can all agree on that part.😂 If you write it first or last, it is up to you and your team, but testing your code is important.
Can you elaborate a bit more on that part? If I understand you correctly, the specifications you are working with are super specific, almost like the tests you would be writing (thus, setting the assertion and expectations).🤔 I might be wrong there.