Greater Saint Louis Area, Missouri, USA
314.482.4111
Sales@TheProductPlug.com

We’re Not Paid to Code

Strategically aligning with our customers needs!

We’re Not Paid to Code

Close to the Metal

I had a conversation with a friend on how Cucumber can be used for testing.

His contention was, it’s more a novelty than anything. So what if your customers or other people can read what the test is doing? It’s not worth spending that time doing that.

My response was: I’d agree, if that were all it were for. But it’s not–it actually helps you by abstracting away the test code so you can focus more on getting the test written quicker, in a way you can understand.

His response was: But I want to get my hands on the code itself. I don’t want to have all that stuff hidden away somewhere, it just feels so… detached.

To which I said: We’re paid to solve problems, not to code.

We Are Problem Solvers

Developers solve problems using code. But you will never find a job description for a dev to come in and just write code. There’s always some kind of business need–somebody needs something, and code is the means to that end.

Test automators also solve problems using code. The problem in this case is we need software that tests software.

But there’s no rule that says you have to be writing a lot of code, in order to do it.

Value Add vs. Lines of Code

A good way to gauge how well you’re doing the job is asking: how much value am I adding?

Here’s a good example: Let’s say you have two people that do test automation.

One person writes the automation directly, in whatever native language is used. The other uses a tool to help abstract away most of the code.

The value add of the second person comes from:

  • how fast the automation can be written
  • how easy it is to understand
  • how much the “Truck Factor” increases
  • how easy the automation is to debug, refactor or extend

 

Mo’ MLOC, Mo’ Problems

There are a couple tenets I live by in this field: Every line of code has to be maintained and Every line of code increases the surface area

There’s still a stigma against test automation code in places. It’s treated like second-class code.

But it’s not. Code is code regardless of who’s writing it.

As such, the same standards apply to it.

Every line of code has to be maintained means, every line of code will eventually have to be touched, debugged, refactored, read and eventually phased out. The more you have of it, the longer it will take to do each of these steps.

Every line of code increases the surface area too. The more code you have, the higher the likelihood of there being a bug somewhere. This is particularly painful when the test automation code itself is where the bug lives.

Businesses care about either making or saving money. Code costs money. The more you have, the more it costs.

Get Off My Lawn, Kid

Maybe I’ve just mellowed out over the years.

No I take that back. Not maybe. I have for sure mellowed out.

I’ve been where my friend is. It’s cool to make a computer do what you want it to do. It’s also a great feeling to scratch an itch with a slick algorithm. It tickles.

And I can think back on projects I’ve worked, and remember what kind of code I wrote, to just bang out a solution, not caring how many lines (or how readable) the code was.

I kinda hope they’re not still using my code at the first tech job I had.

But I’ve been doing this for almost 10 years. And in that time I’ve learned: in business, it’s more important to solve the problem as simply as possible.

It’s a huge mental shift to learn that not all solutions require code, but it’s a learnable thing.

Sometimes you can just talk with people. Sometimes there’s already something written. Sometimes a small amount of code can do the heavy lifting for you.

Very rarely does it require a ton of code to solve a problem–and I would posit that, if your solution does require that much code, the problem hasn’t been broken into small enough pieces.

 

5 Responses

  1. Cucumber still requires code, though. It doesn’t reduce the amount of code needed when compared to a straight up functional test, and it requires a lot more translation effort between Gherkin and your chosen programming language with regular expressions everywhere.

    If no one but you is reading your Gherkin, are you really getting any benefit from using Cucumber? Would you benefit just as much from commenting the Gherkin above your test method and dropping the Cucumber framework althogether?

    • It requires some code, yes. Hope I didn’t imply that we can automate without any code at all 🙂

      But I disagree that it requires more effort than a functional test.

      There was more to the convo between me and my friend, and it had to do with what you’re asking.

      If the code’s been written generically enough… you never have to write that code again. If it’s flexible enough to handle slight grammar changes… those same steps would be reused.

      If you’re a Cucumber user, how much time do you spend writing new code vs. writing specs in Gherkin?

      • No, I didn’t think you meant there was no code in Cucumber. 🙂 I don’t use Cucumber professionally at the moment, though I had been doing until about a year ago, and still use it for my personal projects.

        Yes, it’s flexible enough to handle slightly different ways of phrasing the same thing, which is a really powerful part of Cucumber. I just think that, in terms of code written, a well-structured Cucumber suite and a well-structured functional test suite aren’t that different in terms of code written/maintained.

        When you’re writing functional tests, you do have to write some code every time, but if your architecture and abstraction is good (which it should be, whether you’re using Cucumber or not), that code can be very high-level and quick, and take just as much time as writing a new Gherkin scenario, which is essential for running your code, even if it doesn’t really count as ‘coding’.

        In that case, is Cucumber the best way for you to write tests? It’s abstracted very far out, but if no one else is reading it, what’s the point of going so far as to remove anything code-like from the top level of your automated tests? The value of using Gherkin and Cucumber is mostly in the ability to have other people (particularly non-technicals) read and understand your automated tests, because, as the person who wrote the code, you don’t really need it translating.

        Gherkin steps can be equated to very high-level method calls, so I think the amount of code you have to write is more closely related to how much abstraction you have in your code, rather than which test framework you’re using.

        • That’s a very key question–what IS the point of abstracting that much?

          The answer has to do with my target audience: manual testers.

          I want manual testers to be able to contribute to automation without translating their thoughts into code.

          And I say “contribute” because it’s more than just writing features so that people can read them.

          The way I use it, every line in the feature affects the behavior of the test.

          And those features are what drive the automation. If the feature changes, the test changes too.

          If this sounds crazy I don’t blame you. But I’ve been doing some wild stuff the past few months in this space. It’s working.

          • That’s cool – Cucumber is a great tool to use if you have a test suite that’s mature enough that manual testers can engage with automation at the Gherkin level, that’s a really powerful process to have. 🙂

Comments are closed.