Today I had a chance to see just how well I was doing in my quest to learn Cucumber, RSpec and Ruby, and better move along the project of developing "Behavior Driven Smoke Testing"... naah, no cool acronym there, but it's been an interesting experience nonetheless. The Project that I'm working on is referred to internally as "Mordor", and it seems somewhat fitting. It was actually named by a co-worker with the idea that the "All-seeing Eye" would be checking on everything. Said co-worker was referring to the Eye of Sauron, but he, not really being a Tolkien fan (and he said so himself, I might add ;) ), confused the land of Mordor with the character of Sauron. I explained that the idea of a land surrounded by volcanic mountains that prevented invasion from without but also kept its inhabitants locked in seemed very fitting as a name for a smoke testing project.
As I demoed my tests for the first time in front of the whole engineering group, I had a chance to "defend" my own development work, so to speak. Overall, it was a good experience, and I learned a great deal about how to better implement and approach automated testing from different perspectives.
First, while I was given some praise for the detail and care I'd taken, I was also encouraged to not spend so much time on certain areas. These were smoke tests to check for broad and fast confirmation of functionality, not deep probing examinations of key areas. There would be time for those tests later, but it was wise to have ten tests that covered twenty functional areas rather than having ten tests that covered just one. Currently, I'm closer to the latter than the former, but I'm learning and getting better, so that helps.
Second, while data driven testing is a great method of reusing tests, it can be maddening in that it doesn't give the same kind of feedback a single linear test gives. It's certainly desirable to make tests extensible, but save that for after you have confirmed beyond a reasonable doubt that you have a clean test first.
Third, "red, green refactor" really is a strong as people say it is, and I am progressively worse as we go down that continuum. On the bright side, having gone through several dozen scenarios and scenario outlines now, I'm getting to the point where I don't have to look up each example, and I'm finding where repetitive actions can be grouped together into single line statements and stored in a steps file (you don't have to store just RSpec or ruby statements in a steps file, you can also chain existing cucumber feature statements into single line groupings and use them like a shared library. Yes, I realize that for many out there, this is total master of the obvious type stuff, but for me, this is the first time I feel like I'm really getting traction and making real moves with an automation framework.
Which brings me to fourth; a little every day. If I let a few days slip between making new tests, the rust accumulates fast, but if you give a little bit each day, even if it's just 30 minutes a day, you can keep the momentum moving in your favor. Fortunately, the past few weeks I've been able to get way more than 30 minutes a day.
It's been an interesting experience full of dark and light moments, things that are scary and make no sense, and things that work quickly once you get your flow going. Dare I say it, BDST, and writing tests in Cucumber, RSpec and Ruby is, gasp, actually pretty fun! I'm no great shakes just yet and I doubt that any hardcore Ruby developers need worry about me poaching their jobs just yet, but I am heartened by the fact that i seem to really be getting somewhere with this, finally. Who knows what the next few weeks will bring, but I hope it's ever more green and ever better refactoring. I'm looking forword to it, even if I must walk a dark path to get those skills :).
No comments:
Post a Comment