I linked to this repo awhile back, but it’s worth another mention as more & more people are wanting to learn Go. It also contains a nice write-up on why unit testing and TDD is important.

read more

Mocking is a powerful technique for isolating tests from undesired interactions among components. But often people find their mock isn’t taking effect, and it’s not clear why. Hopefully this explanation will clear things up. Mocking isn’t always the best test isolation technique, but if/when you use it, you might as well use it correctly. Ned’s here to help you do just that.

read more

Some people think that usability is very costly and complex and that user tests should be reserved for the rare web design project with a huge budget and a lavish time schedule. Not true. Elaborate usability tests are a waste of resources. The best results come from testing no more than 5 users and running as many small tests as you can afford. This article is from the year 2000 (queue Conan O’Brien’s side kick), but it’s filled with timeless goodies. Its conclusions are a straight forward example of diminishing returns, but worth reading how they arrived at them from empirical evidence.

read more

Mat and Carmen along with guest panelists Dave Cheney, Peter Bourgon, and Marcel van Lohuizen discuss errors in Go, including the new try proposal. Many questions get answered…What do we think about how errors work in Go? How is it different from other languages/approaches? What do/don’t we like? What don’t we like? How do we handle errors these days? What’s going on with the try proposal?

read more

This interesting testing tool was pointed out to me by Ned Batchelder when he was on The Changelog. It combines human understanding of your problem domain with machine intelligence to improve the quality of your testing process while spending less time writing tests. At its core, Hypothesis is a modern implementation of property based testing, which came out of the Haskell world 20 (!) years ago. Hypothesis runs your tests against a much wider range of scenarios than a human tester could, finding edge cases in your code that you would otherwise have missed. It then turns them into simple and easy to understand failures that save you time and money compared to fixing them if they slipped through the cracks and a user had run into them instead.

read more

Inspired by JSParty #70, 4 quick lessons on the philosophy of testing. The motivation? Tools like Mocha, Jasmine and Jest have made writing tests far easier… But there’s still a gap. It’s extremely hard to find information on the philosophy of testing. What to test and why. How much is enough? What type of tests should I be writing, and when does it fit into my process?

read more

Is testing an art or a science? What and when should we test? What’s the point of testing and can it go too far? We explore all this and more in this jam-packed episode on testing.

read more

Stop wasting time mocking APIs. MockIt gives you an interface to configure and create REAL mocked end points for your applications.

read more

When I first discovered that nine of my tests were failing due to a broken external API, my first thought was, “Man, maybe I should mock out those API calls so my tests don’t fail when the API breaks.” But then I thought about it a little harder… This is why libraries such as VCR are so awesome.

read more

Don’t put off slow tests as an annoyance: do the math on how much time your team is wasting, and then spend a commensurate amount of time speeding it up. A week’s worth of developer time this month will save you a whole lot more over the course of a year.

read more

With prop-sets, you don’t need to outsmart your own code when writing tests. Instead of determining fragile points of failure from particular combinations of inputs, simply generate all possible combinations and assert everything.

read more

We made a silly joke on Twitter yesterday (this is what Twitter is for, no?) about test doubles and that unfortunate moment when they inevitably surprise you. This prompted Shlomo Kraus to reach out and tell us about Mockshot. In brief: Imagine you could: Never manually write a mock again Have a guarantee that your mocks are always valid Sounds nice! It works by using Jest’s snapshot tests output to generate mocks to be used in other tests. This is purposeful coupling, which seems like it could backfire in the long-run. However, the team behind the library has been using it for over a year and are still singing its praises. For more on their experience creating and using it, read this.

read more

Testing code that talks to the database can be slow. Fakes are fast but unrealistic. What to do? With a little help from Docker, you can write tests that run fast, use the real database, are easy to write and run. I tried Itamar’s technique on changelog.com’s test suite and the 679 tests complete in ~17 seconds. The same tests run directly against Postgres complete in ~12 seconds. A net loss for me, but that may have something to do with how Docker for Mac works? I’d love to hear other people’s experiences.

read more

Congrats to all of Mocha’s contributors on what looks like a huge release!

read more

Tanya Janca compares and contrasts quality bugs and security bugs, arguing that they’re quite different and should be treated differently. This logic resonates with me and she has a lot of insights to share along the way. I particularly enjoyed this bit: You cannot have a high-quality product that is insecure; it is an oxymoron. If an application is fast, beautiful and does everything the client asked for, but someone breaks into the first day that it is released, I don’t think you will find anyone willing to call it a high-quality application. A good read all the way through to the end. 👍

read more

This is a great article that covers the 🐛 gamut: spotting bugs reporting bugs reproducing bugs fixing bugs I love the “lifehack” snippets Nikita sprinkles in as well. Like this little gem right here: Lifehack: sometimes you might want to submit a broken code to your branch so it will trigger a CI build. After the build, it will be saved in your project. And your colleagues will be able to link to this problem. Your next commit will have to solve the issue.

read more

Automated tests are immensely useful, but passing tests don’t mean your software is correct. Correctness requires applying human judgement before, during, and after coding, which is why you need additional development techniques beyond just tests. Tests are 💯 a tool in your tool belt, not a silver bullet.

read more

JSONPlaceholder is a free online REST API that you can use whenever you need some fake data. It’s great for tutorials, testing new libraries, sharing code examples, … It comes with a set of 6 common resources. You know, the usual suspects like /posts and /comments. Prefer to use your own data? The whole thing is powered by json-server, which will get you up and running in 30 seconds-ish.

read more

This is a spectacularly thoughtful and insightful piece by Eugen Kiss on testing: Different kinds of tests have different costs and benefits. You have finite resources to distribute into testing. You want to get the most out of your tests, so use the most economic testing approach. He goes on to describe why he believes that integration tests provide better ROI than unit tests and end-to-end tests. Then he turns his aim on unit tests in particular: There is the claim that making your code unit-testable will improve its quality. Many arguments and some empirical evidence in favor of that claim exist so I will put light on the other side… Unit tests ossify the internal structure of the code. Click through to read his whole argument, but I will say in my experience unit tests only ossify the structure when I do them poorly. In other words, the better I get at unit testing, the more useful they become. In light of that, Eugen’s big takeaway at the end might be 💯 on point: If you desire clear, albeit unnuanced, instructions, here is what you should do: Use a typed language. Focus on integration and end-to-end tests. Use unit tests only where they make sense (e.g. pure algorithmic code with complex corner cases). Be economic. Be lean.

read more

Testing React components may be challenging for beginners and experienced developers who have already worked with tests. It may be interesting to compare your own approaches with the ones we use in our project. In order to cover the codebase, you have to know which components must be tested and which code exactly in component should be covered.

read more

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.)

read more

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

read more

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.

read more

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

read more

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. 🐳

read more