4 ms·
""" Engineers responsible for testing, bug fixes, and post-launch maintenance of their own work. there are some unit-testing and integration-testing frameworks
by krosaen 14y ago
"""
Engineers responsible for testing, bug fixes, and post-launch maintenance of their own work. there are some unit-testing and integration-testing frameworks available, but only sporadically used.
"""
Sounds like a lot of code debt accumulating that could bite them hard down the road - it's one thing to write and manually verify bug free code, it's another for a different engineer to make sure he/she doesn't break that code inadvertently a year later when the original author has moved on to another project or company. I'm not talking about 100% test coverage; if the smoke test for a feature breaking is someone noticing while playing with the site, in the long run it strikes me as a much less efficient way to verify and fix regressions than using an automated test suite. Writing good tests is hard, but keeping a product bug free as more and more functionality accumulates without automated test suites is even harder in my experience.
- mkjones 14y agoThis article's about a year and a half old. We have pretty good unit test coverage on a good chunk of our code (especially core stuff), though admittedly not everything. Some groups put particular emphasis on this (e.g. the messages team is great about testing), and it shows in the reliability of their products. Even better, they end up building frameworks that make it easier for the rest of engineering to write tests, and drive the whole ecosystem forward.
- krosaen 14y agoGood to hear. Related: a good article by Eric Ries on how in many situations within a startup technical debt can be used effectively. http://www.startuplessonslearned.com/2009/07/embrace-technical-debt.html http://www.startuplessonslearned.com/2009/07/embrace-technic...