Top challenges a tech-lead faces during projects
Software testing and I clicked early on in my career. The reason is simple - it gives me the confidence to change the code and gives my team confidence to frequently deploy to production.
Continuously analyzing the automated tests I worked with, I noticed some interesting things.
Tests are easy to add, but hard to remove.
My team had more than a few opportunities to take over an application codebase. This often means a new business domain, a new tech stack, new stakeholders.
Removing tests, even obviously bad ones generate a sense of uncertainty - maybe they exist for a reason we don't understand.
Tests know too much.
If the outcome is that the code does not change, a test should not fail. But they often do, and fixing them kills our productivity. What's missing here is the right level of abstraction. Do you sometimes split your screen to write unit tests for your new method? Code on the left, tests on the right? This might lead you to write tests that know too much.
Real data is good data.
How often do you hand-craft the test data your tests use? Does it look similar to production data?
If the test data is not realistic, then what is the value of the test report?
Bugs are detected later in the integration, making them more expensive.
False positives occur as the crafted test data may never appear in that form in production.
Realistic test data also helps me understand the domain behind the code, especially in large codebases.
CDC tests require formal education.
We, developers, are used to writing functional tests. CDC tests have a different purpose, requiring a different mindset in the design. If developers are not educated on the topic, the CDC tests will look more like awkward functional integration tests.