Let's be good internet citizens!
View this email in your browser

Breaking other servers with Node.js »

It's easy to get excited about Node.js and its async programing style - kick off 10 things at once, no problem! But downstream services might have a problem, especially if you have lots of users all kicking off 10 things at once. Let's write Node.js code in a way that respects the limitations of its dependencies - by breaking them first! Read More »

Links of interest... - An intriguing history of the Mozilla logo, involving They Live, Andre the Giant, and graffiti. And of course, open source before open source was a thing! Bonus: A monitor that makes you feel like you're in They Live, and the physics that makes it work. - According to Google's Project Aristotle, "psychological safety" is what makes for a great team. An unexpected conclusion in an industry focused on rock stars! I first heard about this concept at OSFeels in July, during Shawn Rider's excellent talk: Work is Not a Dare. - A fantastic article with specific tips on how to start making the tech space more human, more welcoming for people of all types. A comprehensive bibliography too - if you need more information, or feel like you know the basics already. And, some Seattle-specific discussion in the same vein.


In the last week I've been thinking a lot about the definition for a Unit Test. It's surprisingly hard to nail it down! We know it has to run fast, and it should test one 'unit.' But what's a unit? Even at last week's group discussion at the Seattle Software Craftsmanship Meetup, nobody had a crisp, universally satisfying definition.

This is my definition for a Unit Test:
  1. It runs very fast, a couple milliseconds at most.
  2. During the test, nothing is exercised outside of the project itself - not other services (like databases), not other computers, not other processes.
  3. It tests one 'small' thing - usually one function or class. Likely not beyond one file. Third-party dependencies can be included here, but ensure that they don't violate item #2.
  4. Changes outside that one target of the test should not cause failures.
You might be thinking "but most of my code couldn't even be a potential target of a Unit Test, then!"

To that I say: It might be time to refactor. Most of your tests might actually be Integration Tests, and should be runnable separately since they will take longer. But do we have a good definition for an Integration Test? :0)

Until next week!

Scott Nonnenberg
Unsubscribe or update your preferences.

Copyright © 2016 Gamma Corvi, Inc., All rights reserved.

Email Marketing Powered by Mailchimp