I am, I want to be an engineer. I am not to be classified into cubicles called developer or operations. I don’t want to be a contractor or a consultant. I will not chuck my work over the wall to someone else to test and then move on! I will not inform someone with access to production systems of my migration at the end of an iteration. I will invite them to barbeques! I, Engineer!

I will keep my work transparent. I will talk to my tech leads and seniors and learn. I will say ‘I don’t know!’ when I don’t know. I will argue vociferously when I know I am right. I will listen to other people when they argue vociferously. I will compromise when I am not the only one who is right. I, Engineer!

I do not care what language I have to code in. I do not care what framework I have to use. I will do my best to deliver the best product that can be delivered. I will not rigidly adhere to a methodology for the sake of adhering to a methodology. I will not force a process on my team. I will encourage my team to try adapt processes to the ones that seem natural. I, Engineer!

I will automate my workload as much as I can. I will automate test suites and deployment and provisioning. I will not automate thinking. I will not outsource thinking. I will not contract out thinking. I, Engineer!

I will have a work life balance. I will go home and spend time with my family, a lot of time. I will not spend 20 hours a day at work. I will make sure that no one has to spend 20 hours a day at work.

I, Engineer

Of the languages that I have used in my professional career, Ruby is the one that makes testing easy and fun. It has an easy to understand testing framework and mocking out external classes, most of the time, is very simple. For example:

class Sauron
__def wants
____"the ring"
__end
end

def Gandalf
__def wants
____"peace"
__end
end

class MiddleEarth
__def who_wants_what
____if (Gandalf.wants == peace and Sauron.wants == "the ring") then
______return "war"
____else
______return "peace"
____end
__end
end

Lets say that we have to test out Gandalf or Sauron.
Gandalf.wants.should eql "peace"
Sauron.wants.should eql "the ring"

The above test code is called RSpec and is very simple and easy to understand. Whether it is a Business Analyst or a Project Manager or even your mother, she can fully understand the required behaviour or Gandalf or Sauron.

But what if we had to unit test MiddleEarth? Then we would have to mock Gandalf and Sauron together and alternately to test all code paths. RSpec makes that easy.
Gandalf.should_receive(:wants).and_return("something")
Sauron.should_receive(:wants).and_return("something else")

If either method of either class expected arguments, that too we can deal with.
Sauron.should_receive(:wants).with(something).and_return("something else")

So there you go, testing and mocking made inherently easy with Ruby and its testing frameworks. But how does it compare to the old language of Perl. Perl too, now has a very similar testing framework to RSpec, called Test::Expectation. And for mocking out external influences when unit testing, we have Test::MockObject and Sub::Override.

And if we wanted to business test in either language, cucumber can sit on top of both, although inherently it works much more readily with Ruby/RSpec.