| I find this view (and the replies) interesting. One thing that I've experienced after writing tests a lot is that once you know the patterns, implementing TDD becomes effortless. Eg (python) Need to test interfacing with an SDK correctly? Sure, patch the SDK methods and ensure they are called with the proper parameters Also, for extra coverage, add a long running test that makes actual calls using the SDK. Run these only when lines that directly call the SDK change (and ideally there should only be a few of those). Need to mock a system class? Sure - Here's the saved snippet on how to do that --- This of course applies only if you repeatedly access projects that use the same stack. If you don't then I understand that it can be pretty hard. But basically over time, writing tests must become easier else that's a sign that something in the process is not working correctly. Knowledge isn't being transferred. Or things aren't being done uniformly. Ideally once you get past a certain point, testing should be just a selection of patterns from which you can choose your desired solution to implement against a given scenario. I accept that I could be missing something here so please take what I say within the context that my thinking applies to work that can be described as technologically similar. |