Changelog

Lyndsey Ferguson: Unit testing and the tests themselves are written by humans. Humans are prone to error. Unit tests and the testing infrastructure can be imperfect. The test_center plugin includes tools that remove (or alleviate) the effects of an imperfect test infrastructure. (fastlane is a popular way to automate building/releasing iOS and Android apps.)

This looks really good: 🚀 Fetch & XHR Support ⚡️️ Simple, Powerful, & Intuitive API 💎 First Class Mocha & QUnit Test Helpers 🔥 Intercept, Pass-Through, and Attach Events 📼 Record to Disk or Local Storage ⏱ Slow Down or Speed Up Time

Chris James: Write a simple web server in Go with test driven development. Learn how to use mocking to let you break the problem down into small iterative chunks. All using standard library, source code is available to read. The linked page is a sub-section of the Learn Go with tests GitBook. Do you enjoy TDD and want to learn Go? Or do you enjoy Go and want to learn TDD? Either way, this looks like a great (WIP) resource.

This is the 5th in a series of posts about learning TDD by writing Go. In it, Chris covers dependency injection and shows how simple it can be and how it's a helpful technique for writing reliable and fast tests

The main purpose of the tool is to allow developers to quickly mock API endpoints that for many possible reasons they can't reach at a specific time. Create endpoints which you can then assign static or dynamic responses, cause delays, timeouts. et cetera. Set it up natively or via Docker. 🐳

Yegor Bugayenko: Thread-safety is an important quality of classes in languages/platforms like Java, where we frequently share objects between threads. The issues caused by lack of thread-safety are very difficult to debug, since they are sporadic and almost impossible to reproduce on purpose. How do you test your objects to make sure they are thread-safe? Here is how I'm doing it. Great details on a particularly difficult aspect of testing. ✨

Mihai A: If we agree that a RESTful API should offer more or less the same functionality as the UI, then we can use the same tests for UI automation and for API testing, provided that we make the right abstractions and link them together properly -- this will guarantee that the API is navigable and respects the HATEOAS principle. HATEOAS, for those wondering, stands for Hypermedia As The Engine Of Application State, which is a fancy way of saying the REST application exposes its state (where resources are and how you can interact with them) via hypermedia embedded in API responses. The advantage of this is: A REST client needs no prior knowledge about how to interact with an application or server beyond a generic understanding of hypermedia. In practice, HATEOAS is often left off (which pretty much defeats the purpose of REST, but c'est la vie). The result is a "RESTful" API. Meaning it's like REST but it ain't really REST. I like well-designed RESTful APIs because they are easy to navigate logically, but true REST APIs don't need to be navigated at all, which is way cooler. But I digress, back to Mihai and this excellent post on testing: The code that tests the UI should also test the API. It is achievable, provided that the architect pays as much attention on the tests as he does on the app’s code (which, sadly, is not always the case). He goes on to show example code testing the GitHub API. Good stuff 👌

Monica Dinculescu: I did a little song-and-dance that sets up Puppeteer , takes screenshots of your app (like, all the routes you care about), and then compares them to the “golden” ones. If they match, your test passes! It only works with Chrome (because Puppeteer), but that's not a big deal since this is the kind of thing you only put in your devDependencies. The results are super cool in your test suite output:

Jason Miller (of Preact) released a zero-config wrapper around Karma, Webpack, Jasmine, and Puppeteer. Here's why: Karma, Webpack and Jasmine are all great. They're all also quite powerful and each highly configurable. When creating and maintaining small modules, duplication of these configurations and dependencies is cumbersome.

This is a great introduction to the Mox library written by José Valim and the Plataformatec team. Mox' philosophy: A simple summary is that when it comes to dependency injection, mocks should not be created ad-hoc. Instead, they should be constrained by predefined behaviours. This helps enforce contracts between modules, and it also makes tests easier to maintain and understand. We've been using the Mock library when testing against 3rd party services, and it works as advertised. However, we don't test our controllers in isolation like in this post. Should we be?