13 ms·
Testing at Airbnb
- verelo 13y agoI absolutely love this writeup! Thank you! As someone running a company with around 50 people, and a quickly growing codebase, introducing testing as "a bar so low you can trip over it" is an amazing way to articulate exactly how i feel about this. For us at first we did this by introducing tests on our most complex and commonly used code, that could be run locally. Moving onto using pull requests and having a more robust CI setup to enable more regular deploys is currently the task at hand.
- hoverkraft 13y agoLike testing, PRs are one of those things that seems like it will slow you down, but once you learn how to use them they can actually increase velocity (among many other benefits). It's been awesome to watch how good people have gotten at collaborating/communicating via PRs at Airbnb.
- mathattack 13y agoI like that the URL for this starts with nerds.airbnb.com...
- 5vforest 13y agoWow. I'm surprised at how big they were able to scale, while still pushing most commits directly to master and having a test suite that took 1hr to run.
- deleted 13y ago[deleted]
- seivan 13y agoGreat article! You really don't got a test culture unless you're 'allowed' to take time to debug errors that happens inside the test suite and not the product itself. This is the difference between writing tests and really having a TDD-culture. I mean those issues where the test suites requires maintenance but the actual code base or product is "working". Everyone has had them. I guess it that's what the article means by 'great pain'. Recently I've heard a few non-engineers use "continuos integration" as a way of charging clients more as use per buzz word rules.
- nchuhoai 13y agoPretty 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 :)
- logicallee 13y agoor worse, you can only hit a billion dollars in valuation without testing. (might be a true statement.)
- hoverkraft 13y agoI disagree with this pretty strongly. Somebody posed a similar question in the blog comments, and I think I did a decent job of answering it: http://nerds.airbnb.com/testing-at-airbnb/#comment-13289 http://nerds.airbnb.com/testing-at-airbnb/#comment-13289
- hoka 13y agoyou did. Thanks for answering! I'm definitely the one leading the (small) group of devs who test here. Your article was great motivation for our cause.
- TheRealWatson 13y agoDespite of what developers like to think, success is not linked to technical competence. Achieving the former allows you to address the latter.
- habosa 13y agoThis should be said on HN more often. No text editor, package manager, or library is going to make you a success.
- simon_renoult 13y agoI didn't know HN was about success.
- hiisi 13y agoGreat article! I wonder if the guys are doing code reviews for each PR along with making sure build is green. In our team, we've been doing code reviews for about three years now and can't imagine our workflow without them.
- hoverkraft 13y agoYes, we're absolutely doing code reviews for each PR. Should have mentioned it in the post. Our general policy is to have engineers merge their own PRs, but only after at least 1-2 people have reviewed them (and obviously more for sensitive changes). The dialog that takes place in PRs helps enforce (and sometimes define) our style standards, teach engineers the idioms of a languages they may be new to, and ensure that we're always moving our codebase in the right direction. (They're also a great place to teach people how to write cleaner and less brittle tests!)
- elsbree 13y agoDoes 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 jQuery-based website.
- hoka 13y agoIf you're a python developer, http://www.tdd-django-tutorial.com/ http://www.tdd-django-tutorial.com/ is an excellent resource.
- elsbree 13y agoThanks! Our backend is built on Node, but I'll see if I can glean some general concepts from this.
- jcagalawan 13y agoI found http://www.letscodejavascript.com/ http://www.letscodejavascript.com/ very useful.
- elsbree 13y agoWow, looks really helpful. I'm definitely going to try out their trial. Thanks!
- 2mur 13y agoFor node + browser, I'm partial to substack's tape module[1][2] to output tap. Works great with browserify too. [1] https://github.com/substack/tape https://github.com/substack/tape [2] http://www.catonmat.net/blog/writing-javascript-tests-with-tape/ http://www.catonmat.net/blog/writing-javascript-tests-with-t...
- elsbree 13y ago
- theSshow 13y agoIs pushing directly to master still not disabled to this day?
- hoverkraft 13y agoStill not disabled! Although at this point we're so habituated to PRs as a team that in practice it never happens. We did finally disable force pushes to master, though. Don't miss those one bit.
- Domenic_S 13y agoHow would you even disable that in github?
- davis_m 13y agoIt is very easy to only allow others to pull your repository. It then functions much the same way as an open source project where pull requests are required to get code into the main repo.
- Domenic_S 13y agoYes, but you can't restrict push access to a branch ("restrict master") unless I'm missing something?
- timdorr 13y agoInteresting that you guys went with Solano. We used them back when they were TDDium and found the experience to be very bad. There was notable downtime, a poor interface, and a crappy configuration experience (getting environmental variables into it was very annoying). We've been happily with Codeship ever since. What reasons did you have for choosing Solano? How has your experience been?
- trekky1700 13y agoIronically, 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.
- mattspitz 13y agoIf 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.
- GFischer 13y agoWell, AirBnB is a good example of a startup where the real value - and challenge - was in its novel business model, NOT in the engineering challenges of creating their webpage - which is very nice, but they might have succeeded with a Craigslist-like page for all I know if they solved the problem of creating a marketplace. 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.
- mherrmann 13y agoUnfortunately, I can't read this article on my phone because the layout is so screwed up (Samsung Galaxy SII).