On Mar 2, 2020, at 1:54 PM, Warren Stephens <wsteph...@prognoshealth.com> wrote: > > I have never experienced that writing tests at the beginning saves time. I > find it is always faster to not write them in the beginning. Functionality > typically changes 3 or 4 times before it "settles down" enough that writing > tests makes sense to me.
I'm not a TDD stan in the least, but I have to argue here that if this is the case, you're not spending enough time on requirements and use cases up front. You should be able to write a specification that can be tested against; if that changes in huge, significant ways such that you have to rewrite all your tests, you don't have a spec, you have a draft. I'm aware that that is the reality for a lot of engineers, having worked under both kinds of domains, but that doesn't make it right. Similarly, if your problem with writing tests for your own code refactored by someone else is that you can't understand the dataflow anymore, then the problem is that someone somewhere along the line has not sufficiently documented the code. The solution is not to enable the retroactive insertion of crutches into the internals of a function, especially since tests should be verifying that the external interfaces of the unit under test conform to the specification. Internals should not even be visible to tests, which is why they usually aren't. IMHO we should not be modifying Go to enable poor engineering methodologies, and reactive design is absolutely one of those. - Dave -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/90C6F1DB-92E3-4161-86D4-3D79836A1F4D%40gmail.com.
