Automated testing shows a respect for employees
In the tech-artists.org G+ community page there was a comment on a thread about unit testing:
A key factor in TA tools is the speed at which we need to deliver them, and our audience is considerably smaller than, say, engine tools code. Therefor it becomes somewhat hard to justify the time spent on writing the unit tests, and then maintaining them as the tools change or are ported or updated to match new APIs.
In other words: Testing is great, but we don’t have time for it. Or the common alternative: Testing is great, but it’s not feasible to test what we’re doing.
Codebases without tests manifest themselves in teams that are stressed and overworked due to an ever-increasing workload and firefighting. Velocity goes down over time. Meanwhile, I’ve never known a team with thorough test coverage that delivered slower than a team without automated tests. In fact I’ve observed teams that had no tests and crunched constantly, added tests and became predictable and successful, then removed the tests after idiotic leadership decisions to artificially increase velocity, and watched their velocity drop way down once the testing infrastructure, and especially culture, fell into disrepair.
Companies that do not require automated tests do not respect their employees, and do not care about the long-term health of the company. It’s that simple (or they are incompetent, which is equally likely). We know that no testing results in stress, overwork, and reduced quality. We know that more testing results in more predictability, higher quality, and happier teams. I would love to blame management, but I see this nonchalant attitude about testing just as often among developers.
The “do it fast without tests, or do it slow with tests” attitude is not just wrong, but poisonous. You are going to be the one dealing with your technical debt. You are the bottleneck on call because your stuff breaks. You are the one who doesn’t get to work on new stuff because you spend all your time maintaining your old crap. You are the one who is crunching to tread water on velocity.
I have a simple rule: I will not work at a job that doesn’t have automated testing (or would be in any way inhibited instituting it as the first order of business).
- I have this rule because I love myself and my family. There are enough unavoidable opportunities to interrupt evenings and weekends for work reasons. It is irresponsible to add more ways for things to break.
- I have this rule because I care for the people I work with. I want them to have the same option for work-life balance, and work with me for a long time.
- I have this rule because I want the company I’ve decided to invest in (employment is the most profound investment!) to be successful in the long term. Not until the end of the quarter, or even until I leave, but for a long, long time.
Hi Rob,
For me it’s not about not wanting to write tests, but more about how to go about it. Especially with maxscript where there’s a lot of interaction with the user and scene objects. And many small one-off tools, that either work or not.
I think it’s probably been a long time since you used mxs, but would love to hear some pointers of how to set up such an environment. Thanks!
-Johan
A few things:
– You can use .NET and Python in Max, and both have great testing support. I’d remove or reduce MXS usage (the same way I wouldn’t write MEL anymore in Maya). You’ll need to find or build some automation infrastructure (see https://github.com/rgalanakis/dccautomation). I feel like trying to do automated testing with MAXScript would require extraordinary startup costs, and isn’t worth it now that other options exist. If other options didn’t exist, it’d still be worth spinning up some testing libraries (just base them on Python stuff that already exists).
– I bet those “small, one off tools” actually share quite a bit of logic or libraries. You should train yourself to recognize these commonalities, and learn how to build libraries and reusable code. This can be difficult when programming primarily in DCC apps- try some standalone programming projects.
– Check out my book (http://www.amazon.com/Practical-Programming-Python-Robert-Galanakis/dp/1849694729), even if you are in Max. You’ll pick up useful ideas, I promise.
Hope that helps some, Johan!
Hi Rob, thanks for yout swift reply.
– I do use shared c# components and libraries with database logic. I will take a look at your framework, thanks for sharing!
– I do separate a lot of logic already, like render related code library, UI related functions etc. I’m picking up other languages too, I will keep reading up on it, at some point I know it’s the best way, need to keep pushing myself. I think that’s the main point here. I also see over the years some tools that where vital can get deprecated rather quickly at some point, because of new features or changes in workflow pipeline. How far would you push TDD if it was only you writing/supporting these tools. And they where not overly intricate or complicated?
– I bought your book a month ago ;)
Thanks Rob, it is of help, I never miss a post. It’s interesting following your trials and tribulations!
Cheers!
-Johan
You should actually look for a properly implemented software QA, of which automated testing is one part.
I see this more from a software engineering perspective than one strictly focused on code.
Don’t just check that you are building your product right. Also check that you are building the right product! i.e. one that conforms to your user’s requirements and use cases. If you don’t do that you will not drown in bug reports, but change requests instead (“please fix feature X, please add feature Y, please change behavior of X, please change usability of this…, please change lag of that…”)