Thanks for the info.
Regarding TDD, I feel like there are bad possibilities in both test-first and code-first approaches. I believe that test-first should be a test for whether your feature is functioning as intended from a higher level. Unless you write functionality that isn't yet needed then you should be able to cover nearly 100% of your code with these style tests with positive and negative intention cases. I feel like a test-first approach may be best to get your base feature design, and then some additions after the code is written could assist with your edge cases. You are more likely to know that a number being valued at 257 has a weird blowup after you have written the algorithm that manipulates the data in such a way that 257 renders a zero in that one place over there.
Thanks for the info.
Regarding TDD, I feel like there are bad possibilities in both test-first and code-first approaches. I believe that test-first should be a test for whether your feature is functioning as intended from a higher level. Unless you write functionality that isn't yet needed then you should be able to cover nearly 100% of your code with these style tests with positive and negative intention cases. I feel like a test-first approach may be best to get your base feature design, and then some additions after the code is written could assist with your edge cases. You are more likely to know that a number being valued at 257 has a weird blowup after you have written the algorithm that manipulates the data in such a way that 257 renders a zero in that one place over there.
Great thoughts on that.
This is exactly what I mean about thinking through the implications of a practice or methodology in relation to any given project.