Chris and Eamon kicking things off at Ramen Space for the first MoT London Chapter event.

I'm super excited to anounce our 2026 Ambassadors!! Make sure to follow them on the MoTaverse. And the 2026 Ambassadors of the MoTaverse are........... - Ady Stokes - Ben Dowen - Cassandr...

We wrapped up our first year of Ambassadoring, reflected on it, explored some ideas on how we can improve it. As time came to the end, I was saying thank you and wasn't sure how to say goodbye,...

Found a quiet moment between projects to break out the TestSphere deck. It’s a great way to step back from the "how" of testing and remember the "why." Looking at cards like Interruption and Requir...

What happens when you have 99 seconds to look at someone's MoT profile?

A handler is a piece of code that responds to something happening — like a message arriving, a request being made, or an event being triggered.Think of it like a receptionist at an office: Someone walks in (an event or message). The receptionist (the handler) decides what to do — maybe call someone, give directions, or log the visit. When something happens — for example, a user clicks a button, a message arrives, or a request comes to a web server — the system passes that “event” to the right handler, which knows what to do next.In software, a handler does the same: It receives input (like an API request or a message from a queue). It processes that input — maybe by saving data, calling another service, or sending a response. As a tester, you might encounter handlers in: APIs: A handler processes incoming HTTP requests (e.g., GET or POST). Message-based systems (like NServiceBus): A handler processes messages sent between services. AnalogyImagine a smart home: You press a button (event). The system runs a handler that turns on the lights. As a tester, you’d check: Did the lights actually turn on? What happens if the button is pressed twice? What if the handler fails? Event-driven systems: A handler reacts when something happens (e.g., a user signs up) Understanding handlers helps you: Know where the logic lives — so you can test the right thing. Understand how data flows throughout the system. Spot side effects — like database updates or messages sent. Write better unit or integration tests by targeting the handler’s behaviour.