3 ms·

I do not have a solid stance, but I am inconsistent on writing tests. I like to differentiate between the notions of hand-testing code and automated-testing co

by Xurinos 15y ago

I do not have a solid stance, but I am inconsistent on writing tests. I like to differentiate between the notions of hand-testing code and automated-testing code. I firmly believe code written should be verified somehow. I have not totally bought into writing tests. Right now, there is a lot of snake oil about what is better than what, and I would like to see good scientific studies that point in solid directions. Some of the blur is caused by different kinds of programmer experience. We have to work with the "art" and "creativity" variable here, along with "has seen a similar pattern before". The other problem is asking the right question: What kinds of testing can create a consistent and solid improvement in acquiring money (or some other important pointy-haired boss measurement) over a 10-year period of time? There are things that can make us feel good, nice placebos. For example, 100% test coverage is known to not equate to good, working, maintainable code: you may be missing features or doing things completely wrong, but your tests validate that your wrong thing or lack of thing is working. Is there a magic bullet? Probably not... but it is widely believed (and probably justifiably so) that automated testing helps somehow. People will expound on the benefits. Personally, I want numbers. I want to know the pain before the tests and the less pain afterward. I want to know confidently that the time spent writing tests as part of development is less than the time spent discovering and fixing problems. Note the careful wording there.

nasmorn 15y ago
I am not so big on unit tests because I feel I mostly write glue code in rails were the problems are really not very hard. What I really like is Selenium test that work like manual testing and I thus feel they just automate something I would need to do in any case.
- Xurinos 15y ago
  I agree; I like the idea of Selenium for web GUIs. I remember wanting to write my own similar tester for Win32 GUIs a while back, but I ultimately did not see enough value in it. For the same reason, I do not use Selenium: you have to completely "rewrite" the tests to adapt to small interface changes. So I wrote up test plans for humans to run, and they could adapt to the changes; it was faster than writing an AI. ;) At an old job, we had what was called "random testing". This was a time to relax and take a few hours to pound at the application with whatever we could think of. With luck, someone would go ahead and attempt to automate those tests. One of our favorite "random" tests was to start some complicated process and then shake the window all around the screen to see if it would crash -- sometimes it did! It forces people to rethink their threading approaches. Another fun trick is closing an app mid-processing; does it exit gracefully?

by Xurinos 15y ago

nasmorn 15y ago

I am not so big on unit tests because I feel I mostly write glue code in rails were the problems are really not very hard. What I really like is Selenium test that work like manual testing and I thus feel they just automate something I would need to do in any case.

Xurinos 15y ago
I agree; I like the idea of Selenium for web GUIs. I remember wanting to write my own similar tester for Win32 GUIs a while back, but I ultimately did not see enough value in it. For the same reason, I do not use Selenium: you have to completely "rewrite" the tests to adapt to small interface changes. So I wrote up test plans for humans to run, and they could adapt to the changes; it was faster than writing an AI. ;) At an old job, we had what was called "random testing". This was a time to relax and take a few hours to pound at the application with whatever we could think of. With luck, someone would go ahead and attempt to automate those tests. One of our favorite "random" tests was to start some complicated process and then shake the window all around the screen to see if it would crash -- sometimes it did! It forces people to rethink their threading approaches. Another fun trick is closing an app mid-processing; does it exit gracefully?