When they asked if I’d ever written unit tests, I pointed out that it’s clearly mentioned in my CV. I’ve worked with unit tests in several projects, so it wasn’t a matter of whether I could, but more about how I approach them. They followed up with a question on defining and using data in tests — particularly in a controller or model scenario. I explained that, in my experience, I would define the data separately, close to the test cases, for reuse and clarity. This way, you ensure that each test has the necessary data without redundancy. It’s a standard practice for managing test data and ensuring clean tests. Then came the question about mocks. I’ve used mock objects in testing before, so I was ready for it. The question caught me off guard a little because of how it was phrased, but I quickly regrouped. I responded that I’d look at the existing tests in the codebase for examples of how mocks were set up, and adapt them to the new test cases. While I hadn’t written mocks in a little while, I knew exactly where to go to review and implement them properly. I believe the real-world experience of working with codebases, existing tests, and adapting them is far more valuable than rote memorization of mock syntax. So even if I hadn’t worked with them recently, I know exactly how I’d handle the situation. It wasn’t a lack of knowledge — just a reminder that working with a well-organized codebase, or reviewing previous examples, is the most efficient way to tackle such tasks.