41–50 of 58 posts
Does anybody have recommendations for where/how to start learning best practices for TDD? As (nominally) top nerd at a tiny startup (2 engineers), I feel like I should set a precedent sooner rather than later for testing. This is currently not possible since I don't know anything about it, so any resources would be appreciated :) Edit: Primarily looking for resources involving Node.js and client-side testing of a jQu…
Pretty interesting that according to him, Airbnb didn't really have a functioning testing infrastructure only a year ago. So you really can hit a billion dollars in valuation without testing :)
Pretty interesting that according to him, Airbnb didn't really have a functioning testing infrastructure only a year ago. So you really can hit a billion dollars in valuation without testing :)
The technical infrastructure and code quality of a company are secondary factors in its success. The biggest influence they have is in the ability to attract and retain brilliant engineers, because most brilliant engineers don't want to work in a place where they're just treading water with bugfixes (which is the situation you eventually get into without automated testing). But the mechanism is that brilliant engineers write features that your competitors can't match, not that testing itself will make you successful.
Pretty interesting that according to him, Airbnb didn't really have a functioning testing infrastructure only a year ago. So you really can hit a billion dollars in valuation without testing :)
Despite of what developers like to think, success is not linked to technical competence. Achieving the former allows you to address the latter.
Ironically, AngelList posted a slideshow the other day about how they don't use tests because they increase development time and make it hard to be agile. They instead iterate quickly, pushing out new versions and fixing rapidly as things come up.
The irony is that AngelList allegedly generates funding for real engineering teams.
Earlier quoted context omitted.
Despite of what developers like to think, success is not linked to technical competence. Achieving the former allows you to address the latter.
This should be said on HN more often. No text editor, package manager, or library is going to make you a success.
Earlier quoted context omitted.
Despite of what developers like to think, success is not linked to technical competence. Achieving the former allows you to address the latter.
This is one reason I'm moving back to the LAMP stack. It's ugly, boring, and cheap. Great for prototyping.
Ironically, AngelList posted a slideshow the other day about how they don't use tests because they increase development time and make it hard to be agile. They instead iterate quickly, pushing out new versions and fixing rapidly as things come up.
If you can test everything manually with confidence that every incremental change breaks nothing you've ever thought about prior to the present, I suggest you work on more complicated things. Otherwise, you're mistaken. The irony is that AngelList allegedly generates funding for real engineering teams.
So I agree with the general idea behind what AngelList is saying. If the startup value proposition is based on solving a "hard " engineering problem, OTOH, it's not such a good idea... but it seems that most problems startups tackle are NOT engineering problems.
Does anybody have recommendations for where/how to start learning best practices for TDD? As (nominally) top nerd at a tiny startup (2 engineers), I feel like I should set a precedent sooner rather than later for testing. This is currently not possible since I don't know anything about it, so any resources would be appreciated :) Edit: Primarily looking for resources involving Node.js and client-side testing of a jQu…
http://www.sustainabletdd.com/
One aha moment for me that's talked about here is to treat your tests more as a form of documentation and specification of how to use the system. They talk about how you should even do some basic tests to confirm enumerations and constants in the system as a way to be clear about their use.
You don't always have to be as thorough, but the mental shift from test to specification was helpful for me.
Edit: Unfortunately, if you download this podcast it's a bit out of order, so you want to read the blog and use it as a guide for which order to listen to things. They're in the process of writing a book about TDD and this blog is part of their process.