#EmberJS2018: Keep Leading with Testing
“The testing story in Ember is something that is very understated. Ember has created a testing harness that would be the envy of any other language/framework. After consulting for many years now I can say that there are few things as important as having a rock solid test suite.”
- Jonathan Jackson, Blog Post for an Ambitious Framework
Hi, I’m Benjamin, an engineer at Percy working with Ember. I wrote this article in response to the Roadmap RFC from Team Ember to propose “goals and directions for Ember in the remainder of 2018.” My team and I love tests of all kinds. To me, testing has been a core part of my Ember experience. I want to see more people discover that testing in Ember is awesome and to see Ember grow to accommodate more testing styles. I think that the testing experience isn’t given enough weight in our discussions about web frameworks and would like to see that change.
Testing in Ember is awesome and is getting more awesome all the time. Some recent updates that make testing in Ember even better include Testing Simplification and Acceptance Testing improvements. A lot of people outside of Ember don’t know about Ember’s built-in support for unit, integration and acceptance tests. They don’t know Ember’s generators magically create useful test files. They don’t know about the browser UI for interacting with the test suite while you work. I enjoy the benefits of Ember’s improvements to testing, but I would like to see those benefits demonstrated in more vocal and visible ways to the rest of the front-end web community. The testing story should be front and center to Ember’s identity. It should be featured in more posts, tutorials, presentations and code examples.
Testing JavaScript isn’t always easy. Convincing others to write and maintain tests isn’t always fun. I have spent a lot of time explaining to fellow developers that they should write tests, or more tests, or better tests. Once we agree on this, it’s daunting to decide which test libraries to use, integrate them into the build, and determine overall test strategies to employ. Ember (in the footsteps of Ruby on Rails) handles a lot of this for you by establishing testing conventions and structures out-of-the-box. If you don’t know where to put your tests or how to get them going, voila! It’s taken care of and you can just fill in the gaps. This is a huge win for teams with cold feet when it comes to testing an application. In my experience getting from zero tests to a few simple tests is a big conceptual hurdle for people who lack testing expertise. It is much easier and faster to look at Ember’s default tests and then build out more in the same fashion.
These conventions don’t work for everyone. In 2018 and beyond, Ember needs to strike a balance between convention and configuration such that choosing between a handful of popular libraries is a good experience. Not everybody wants to use QUnit. I prefer Mocha or Jest. While it has been fairly simple to replace QUnit with Mocha in an ember app, support for Mocha often lags behind, and Jest support is absent. We should support QUnit, Mocha, and Jest like how we support CSS, LESS, and Sass. Other posts in this series have emphasized the need to similarly improve TypeScript support. The defaults and conventions are really useful, but I think it should be easier for developers to change them. People experienced in other ways of writing tests can be quickly turned off or confused when trying to re-configure Ember to test in the style they prefer.
“I’d love to see a tighter integration of visual integration tests into Ember as one of the core “best practices” methods that Ember apps are tested.”
- Andrew Callahan, A Road to Ember 4.0
The way we test applications is evolving. Ember is in a great position to keep leading this evolution. Building Percy (and using Percy to build Percy), has opened my eyes to the power of visual regression testing. Percy has excellent support for Ember, and Percy’s web client itself is written in Ember. Visual testing is a paradigm shift because it captures pixel changes without the need to manually write a test. Generative testing could be another paradigm shift we may choose to explore. Many other innovative projects such as Cypress, Storybook, Flow and Enzyme each offer new ideas to learn from and potentially incorporate into Ember.
As Ember keeps improving, we can continue to be a voice of wisdom for application testing paradigms. And we can do so a little less quietly.
