Engineering practices @ Meta: #4 Engineers write automated tests, well mostly! 😉

At meta, Software engineers/developers own writing tests for their features and code, They are supported by dedicated teams and a sophisticated test infra though.

Photo by Christina @ wocintechchat.com on Unsplash

At Meta, Software Engineers author most of the automated tests that get written. 

Developers write unit, integration, and E2E tests. 

There are distinct Testing frameworks to enable them to write these most optimally with multi-quality gates like:

• Local and CI Linters checking if standards are adhered to

• Engineers can use optimized test infra and test services while authoring and running tests. 

• The data is heavily instrumented with loads of options to derive metrics and it’s easy to plot beautiful graphs and reason about tests performance and reliability.

• Devs are notified and reminded to fix and resolve quality issues with their tests.

In most startups, there are separate Dev and QA roles with a clear separation of responsibilities, and while devs author some unit and integration tests, it’s quite rare to see devs also adopt E2E testing frameworks as first-class citizens. 

Meta has a distinct engineering culture regarding this industry pattern.

Does this mean that there is no QA or SDET presence within the company at all?

Not really …

Meta is a pretty big company with multiple products and lines of business. I have come across engineers having the role of an SDET or QA but this is in certain products and verticals and not a universal phenomenon and I particularly experienced this while working for WhatsApp.

Large-scale exploratory testing is mainly outsourced to companies than full-time employees and there are QA Engineering Leads who co-ordinate and make sure this is done and managed in the most efficient manner possible. 

Multiple platform teams work hard to keep the test infra and frameworks pristine and scalable for thousands of engineers.

This approach has some distinct benefits, such as a lot of tests being written for a change or feature. Since devs own automated tests they also are incentivized to keep them of higher quality. 

However, even with all that, the tests are not immune to test flakiness and it’s still an area of work that teams actively work towards improving. The no of tests is huge, but are they written in the smartest and most effective manner? This is a topic for another time and reflection.

I also discussed a bit more about this practice in this blog, Please feel free to read that for future context.