Operations | Monitoring | ITSM | DevOps | Cloud

All developers have seen them, even in well-structured Golang programs: comments suggesting you keep away from lines of code since they seem to be working in a magic way. These warnings make us timid, fearing we might break something. But applications need to change, to improve and innovate. That’s why unit tests are a vital part of software development. They help developers know whether the small parts of their software perform their intended function correctly.

Have you ever wondered how many active users your application can handle at the same time? If so, you’re not alone. Here at Mattermost, we’re building a highly concurrent messaging platform for team collaboration that needs to potentially serve up to several thousands of users simultaneously.

Every software organization has long balanced the interlock between software developers and software quality assurance testers. While developers aim to build software to business requirements, it’s the QA team’s job to verify that they actually did.

The ultimate goal of writing tests should be improving the user’s in-app experience and increasing developers’ confidence in shipping new or improved apps. The Mattermost team has been continuously writing different types of tests to improve the product. Such extensive automated testing has enabled them to ship a new release—with new features and improvements—every single month for the last few years. Thousands of developers contribute to the codebase.

After weeks of writing, researching and hopefully enough proofreading, we just launched a living collection of practical guides on leveraging headless browser tools (starting with Puppeteer and Playwright) for testing, monitoring, scraping, performance measuring and more. We called it theheadless.dev. This article is about the different approaches we tried in contributing ideas to the Puppeteer community, as well as the principles that guide our latest contribution.