The Meteor Testing Manual is now Quality Faster

Notice to new users

In 2014, I began writing The Meteor Testing Manual. I wrote around six chapters as I wrote Velocity, which was the official testing framework for Meteor at the time. Back then Meteor was not modular, it was difficult to test, and it was continuously evolving. This was particularly challenging as I had a constantly moving target to write both Velocity and the book for.

Things are different now however and Meteor has changed significantly. Modularity has become a central part of Meteor and this is huge for testing, and the testing tools that are available today are light-years ahead of the tools we had 4 years ago. As such, I've decided to stop writing the old guide, and I'm replacing it with a newer, better guide called Quality Faster.

Where the original book was exclusively written for Meteor, Quality Faster is aimed at both Node.js and Meteor. For example, it will show you how you can start to build an app in Meteor and then deploy parts of to serverless targets. Moreover, Quality Faster covers much more than just development, and it's a guide for entire teams.

Please see the homepage for more details, and sign up to get notified when the new guide is ready, and if you so feel inclined, feel free to read the notice to existing users below.

Thanks for looking, and I look forward to helping you deliver higher Quality Faster.

Sam :)

Notice to existing users

TLDR; "Quality Faster" is the new guide that I'm writing. It contains all the things that I wanted to include in The Meteor Testing Manual and much, much more, and it will be available to you at no extra cost. You will be notified when it's ready so no need to take any action on your part.

A huge thank you!

First of all, I want to say I'm eternally grateful for your support and trust when you purchased The Meteor Testing Manual. I recognize that it's been a long time since the last update, but I want you to know that I have not given up on writing the content that I promised, and that you will be getting a lot more than what you paid for.

I would also like apologize for the time it is taking me to deliver on that promise. I owe you an explanation, so please allow me to tell you my story, and where things are headed.

Rough Times

In 2012, I was working on my startup called Spaces, for which I had created a framework that was like a mini version of Meteor. Then I discovered Meteor and decided to rewrite the app using Meteor so I could worry less about the framework and more about the app I was building.

However, as an Agile coach and TDD practitioner, it bugged me that Meteor didn't have a testing framework and I so I set out about writing my own. I wanted something that worked in a similar fashion to Meteor, where every file save not only rebuilt the app for you, but also ran a full gamut of tests. So, created RTD (Real Time Development), I open-sourced it and did a talk about it.

Months passed and in 2013, I quit my job and worked full time on my startup. I got deeper and deeper into the Meteor testing world and met a few folks enthusiastic about testing, and then the Velocity framework was born which later became the "Official testing framework of Meteor 1.0".

Unfortunately, none of the core Velocity team members were being compensated and instead we had to consult with clients that used Meteor in order to keep Velocity and ourselves alive. As I was living in San Francisco, this was hard!

In order to fund myself and drive the development of Velocity forward, I came up with the idea of creating The Meteor Testing Manual around 2014 and the response from the community was great, however the income was not enough for me to solely depend on so I started seeking and carrying out more consulting gigs, all of which took my time away from being able to work on Velocity and on the book, despite my best efforts, and this led to delays and more delays.

Journey into the deep

And then there was something else. While I felt I was qualified to write the book as a TDD practitioner, there was a gap in my knowledge that deeply bugged me. I couldn't quite place a finger on where this gap was, but I know it was there.

Readers of the book and clients alike would ask me questions like:

When should I write an integration test vs an end-to-end test?
How do I know what to put in a given/when/then scenario?
How can ensure everything works without writing end-to-end tests?

And while I had adequate answers, I didn't have unequivocal answers and I knew that I lacked the depth of understanding that I like to have when teaching others. So I set out on a journey to learn this depth, and I was haunted with this question:

What does the perfect automated testing strategy look like?

Because even if perfection can't be achieved, I believe that having a picture of perfection allows one to understand and make compromises where needed.

This journey took me high and low.

I consulted with many clients from small start-ups to large enterprises and everything in between, and I trained folks across whole organizations, from leaders to UX designers, and from testers to developers.

I created an open-source acceptance testing framework called Chimp, and a SaaS product called Simian, both of which I used in my consulting and were related to automated testing. I then killed Simian and wrote a new improved version called XSpecs, which I'm still working on today.

I investigated, experimented with, and applied pretty much every testing technique out there. I practiced Behaviour Driven Development to the level that I became a Cucumber trainer, I implemented Hexagonal Architecture with Domain Driven Design and Command Query Responsibility Segregation in XSpecs and for clients, and I understood the these techniques at a nuts-and-bolts level.

Realizations

4 years later, I have emerged from the depths and believe I've discovered the essence of software quality, along with other realizations about the whole product development lifecycle.

I've realized that testing is not just about programming techniques, and has a lot to do with communication, specifications, design and architecture. Testing starts with having the right team members effectively collaborate before a single line of code is written. I've realized that there are are significant non-development related techniques to teach in addition to the technical portions for testing strategies to succeed. And I've realized that within the coding realm, making the correct design and architecture decisions makes the writing of tests and code a lot faster and simpler, and of course the inverse is also true.

What's next?

I am now putting this knowledge and realizations that I've learned, which spans across the entire product development lifecycle and across the whole team, into a guide that helps you and your organization deliver higher quality software, faster. The guide is called Quality Faster, and I'm packing with the theoretical and practical knowledge required for everyone involved in creating software products.

You will learn the breadth and depth of the following areas:

Gathering requirements and writing specifications
Designing testable and maintainable software architecture
Writing automated tests that are fast and reliable
Deploying code to production continuously
Learning and improving your product, system and process
And much, much more

The guide starts with the fundamentals and then goes through iterations, where iteration 0 teaches you how to get set up and the subsequent iterations show you how to manage the increasing complexity of building apps. Please see the homepage for more details, and no need to sign up as I have your details and I will send you an update before I release the beta version.

I'm planning to have the fundamentals and iteration 0 completed in the next few months, and to complete the guide throughout 2019.

Again, I want to thank you for being supporters of The Meteor Testing Manual, and I look forward to helping you deliver higher Quality Faster.

Sam :)