Some thoughts on testing.. 5
http://blog.edgecase.com/2009/6/2/a-rant-about-testing
It got me thinking about my feelings on testing in general. Yes, I'll raise my hand, I'm totally not the best person to talk to for being thorough with my testing. Honestly, I'm just not drawn to it. The way I learn new technologies and develop software is very much reactionary to a personal drive to do or build a given thing. Something in my head tells me that I need to drive a certain thing into the ground, and then I just do. Unfortunately, testing doesn't seem to get first billing with that drive. I have to say though, once I get into it I can in fact make good thorough tests and they inevitably save me later. Its just getting that kick-start to go down the road of testing is the tough part.
My worst flaw by far, though, is that while I may test a feature and ensure that it works how I intended it, I don't necessarily create a "Test" for that feature. What I mean by this is that someone who is not me, can't just run a test script to re-do my method of testing, and see if any changes have broken things. If i could get into that habit in general, whether it be at integration or lower, I'd probably be way better off when i start making some serious Rails applications. That or I need to find me a Testing Monkey. Someone who, for whatever reason, doesn't want to build things, but instead wants to break things.
Yeah I think i really need to go the route of a test monkey, that's the ticket....
Trackbacks
Use the following link to trackback from your own site:
http://acts-as.iammikesdomain.com/trackbacks?article_id=4
Testing monkey, huh? Did you forget what I do? (Current title: Senior QA Analyst).
While I’m not a programmer, I do on occasion script some junk and one thing I sometimes do is write the black box tests before I code the function/feature. Since black box requires no knowledge of how the thing works (something goes in, invisible magic happens, and something comes out) you can write (or outline) very simple tests based on input = expected result.
Throw in entries for boundary conditions and full on error handling and all of a sudden you not only have a basic test script to validate your work but something almost akin to requirements (so you don’t forget anything like good error reporting which is what I usually do). Think of it this way, if it’s a good practice to comment your code, why not comment the design process as well? Those design comments are usually pretty good tests.
Obviously, that’s not a 100% foolproof testing methodology. Working with arrays requires different testing then if you are working with strings but that’s whitebox/clearbox testing and a different topic altogether.
So you’re volunteering to be my test money Hojo?
Hired!
Yeah I’ll help out. I like to break things and I tend to be pretty good at it. It means I’m going to need documented requirements to test against. And cupcakes… with sprinkles.
Cupcakes and sprinkles i can provide. Instead of requirements, I give you some beer and a vague outline of what I was hoping to do with it ;).
I can work with a vague outline. Now I think I left my email with the previous post and did not receive any kind of notification so I’m leaving it again with this post to see if I get anything. See, testing.