Well written, well said:
http://artificialcode.blogspot.com/2010/04/professionalism-in-python-or-how-to-not.html
“My take on that is if you are employed as a professional Python software developer, then not writing tests is lazy, unprofessional, and unacceptable…period.”
“Robert mentioned that Ward Cunnigham’s idea of “clean code”, was that it was obvious what a function did. This isn’t as easy as it sounds. In fact, this is a lot of hard work, even with a language as beautiful, and elegant as Python.”
Dunning–Kruger effect:
http://en.wikipedia.org/wiki/Dunning–Kruger_effect
“”Powerful tools kill quickly, and in surprising ways, and we are going to be careful…. ” Often in a failed or troubled Python project, you will see a lot of code where someone was making a mess by trying to be cute.”
“My take on that is if you are employed as a professional Python software developer, then not writing tests is lazy, unprofessional, and unacceptable…period.”
I don’t like this sort of dogmatic blanket statement. In the project I’m currently working on the design (or rather specification) is being revised so frequently that if I were to do proper testing, I would spend at least half my time rewriting the tests again and again. I did start writing a test suite, but it is now unmaintained because of sheer rate of changes that broke the tests (broke them in the right way – the desired behavior changed). As it is, there are deadlines looming that may or may not be reached with all desired features.
The reality is that sometimes you aren’t coding under ideal conditions. Sometimes a client/employer’s priority is getting something done as quickly as possible for as little as possible, because they are under different business pressures. Tests are filed under “features we’d like to have far off in the future”.
As I have been told: “you are not being paid to write tests”.
Yes, I absolutely agree with you. I have been working under the same circumstances with my company for four years, where we design a single binary compiled from C++ – and running it is our only test case.
I have recently been adding small test cases here and there because we were able to hire another person to relieve my workload, and I also have become comfortable and familiar enough with our workflow to start at least writing some for my own code.
As far as python code goes, we embed a python interpreter into our C++ application, and have a completely hacked method of executing python code. I actually create the module object using PyModule_New, add our engine api objects directly to it, and compile and run the code manually and handle all exceptions manually. 95% of python code executed exists in these relatively short modules that do not use any imports, and produce output that is heard and not seen. Thus, it is impossible to write unit tests in the traditional sense.
I do like the quote though, because being able to write tests that ensure the quality of your code can completely change the way you develop your code. I think designing your architecture to facilitate the writing of tests is something to strive for.
Further, I have started writing small tests (see a related post about four posts ago) for my C++ code at the bottom of appropriate .cpp files. The test objects are simple, are static so they get run really quickly instead of waiting for our engine and gui to start up, and has saved me an incredible amount of time. I still don’t have tests for our python code, but I have refined the workflow enough over the last 2.5 years and ensured accurate function of various tools (script output console and good keyboard shortcuts, for example) that you can actually do pretty well with it.