4 ms·
I constantly have problems with people posting the same information on unit tests, again and again. I know how to set up (for example) RSpec, MiniTest, Cucumber
by colinramsay 12y ago
I constantly have problems with people posting the same information on unit tests, again and again. I know how to set up (for example) RSpec, MiniTest, Cucumber, FactoryGirl. The thing that people struggle with is how to use these in a larger, practical sense, rather than in just the trivial. I think this puts a lot of people off testing.
- Tyguy7 12y agoAgreed. I have only used TDD once as a front-end web developer, and I've found that I do struggle with the practicality of it. I spent half my time managing and maintaining my tests. When I did the math, It seemed that all that extra time spent was more than It would have taken to simply chase down bugs that would have arisen in a non-tdd environment. It just seems to take more time than is practical. Especially in agile startups.
- CmonDev 12y agoActually in this case he seems to be past his personal TDD hype peak: "... a proponent of the selective use of Test-Driven Development." Hopefully this will become a mainstream thought. Then maybe we will fix the legacy browser languages problem. Man can dream...
- ZeroGravitas 12y agoIs the only metric your time spent preventing/chasing bugs? What if those bugs get out to the customer and impact them?
- deleted 12y ago[deleted]
- atilaneves 12y agoPerhaps. The difference is that in one case you'll have the machine automatically tell you when and why your code stops working because of a regression, and in the other you have no clue until the customer hits it. It's not only about proving it worked once, it's about proving it with every commit.
- jpindar 12y agoThere's a difference between TDD and having unit tests!
- ereyes01 12y agohttp://blog.8thlight.com/uncle-bob/2013/09/23/Test-first.html http://blog.8thlight.com/uncle-bob/2013/09/23/Test-first.htm... Read that and read oldie, but goodie Extreme Programming Explained, and IMO they do a good job of painting the bigger picture. TL;DR Tests are live specs that break when you change the underlying spec of your code without updating the spec in the test. If you can express your code's spec in a test, then you have a much higher chance of deeply understanding your design... hence the article's recommendation that you first know what you are doing before diving into writing tests. As for tests in the larger practical sense vs. the trivial... The vast majority of large systems are compositions of small, seemingly trivial pieces. A large system's code needs to be organized so that all its component pieces/concerns are comprehensible and separate; otherwise, it's an unmaintainable monolithic soup. The unit tests adhere to the same principle, in general, and follow the composition of the system.