The Future of Chimp.js

The Chimp.js that you know and love is now being split into two separate projects, both of which are intended to help you deliver higher quality faster. These projects are Chimpy and Chimp 2.0, which you can read more about below.

Chimpy logo. Shows an orange monkey inside a circle.

Chimpy (formerly Chimp 1.0)

The first project is Chimpy, which will be developed and maintained by The Brain Software House. This project will continue to be evolved and supported with the original thinking behind Chimp.

The Brain Software House has been instrumental in the development of Chimp and has also been a long-time partner of We have worked together on many quality-first assignments and for many clients. I’m ecstatic that they are the ones who are continuing to carry the original Chimp testing framework through.

As part of taking on Chimpy, they have just added a long-requested feature, which is the ability to retry failed tests. This is a technique that they use when running over 1,000 acceptance tests using Chimp for some of their clients!

If you’re interested in a quality-first development house, you should get in touch with them.

Chimp.js Logo. Shows an illustration of a chimpanzee and the word “chimp.js”

Chimp 2.0

The second project is Chimp 2.0, which will be developed and maintained by

Let me start with the backstory:

In April 2013, I wrote my first testing framework called RTD. I wanted to create a testing framework that not only made it easy to put quality first, but one that also made it a pleasurable experience for developers.

I was inspired by Meteor’s approach to development, and I designed RTD to work in a similar fashion, where every save would result in test runs that ran quickly in order to provide fast feedback. I followed this quality-first, fast-feedback pursuit in the subsequent testing frameworks that I wrote, which were Velocity, Meteor Cucumber, and Chimp.

With every new testing framework I wrote, I learnt new lessons and realized that while fast feedback is important, it’s not as important as getting the architecture of an application right. That is,

a badly architected codebase is difficult to test, no matter which techniques you use.

I’ve also realized that testing an application through the UI is slower, less reliable and more expensive than other and better techniques out there, and that UI tests should be used very wisely and not liberally.

Every testing framework that I wrote tried to improve the speed, reliability and cost of UI based tests, and Chimp 1.0 did that to a very high degree. So if you’re wanting to write UI based acceptance tests, then Chimpy will help you do exactly that and do it very well.

However, an automated test strategy that allows developers to write fast, reliable and cheap tests is not obvious, it does not start with the UI, and it requires a paradigm shift in the way that an application is designed in the first place. This is primarily a knowledge problem and secondarily a discipline problem. A person or a team needs to first learn these quality practices and then have the discipline to stick to them as opposed to resorting to old habits.

Quality Faster logo. A logo showing linked circles with the words “Quality Faster”.

So I set out to provide this knowledge in a new guide I’m writing called Quality Faster, which you can preview here. This will help you and your team understand at an experiential level how to apply a quality-first, fast-feedback practice that helps accelerate your product development lifecycle.

As for the discipline problem, this is where Chimp 2.0 comes in. Instead of only being a UI testing framework, Chimp will help instill the right behaviours by putting in guardrails that prevent you from resorting to old habits and adding new capabilities that allow you to write higher quality software, faster.

Chimp 2.0 will be a Yoeman for quality. The intention is to have Chimp be your companion that you can call on to generate stubs and boilerplate code for you with good design patterns, domain driven design concepts, the separation of concerns principle, and code that is optimized for change.

You may be wondering why I’ve decided to keep the name Chimp and split out Chimpy instead of just creating a new project. Well, I want to make a point that it’s important to change direction when there’s a better way. So as I’m asking developers to change the way in which they think in order to improve speed and quality, I’m also changing the way in which Chimp works to provide the tools to get that speed and quality.

I’ll be dedicating time to work on Quality Faster and Chimp 2.0 from January of 2019.

Let me know if you have any thoughts or feedback, and I look forward to helping you deliver Quality Faster.