Saturday, May 15, 2021

Pull the Other One

When I changed jobs recently, joining a team responsible for a middleware server, I expected that much of my work would be against its API. This has proved correct, although I've been able to test at all layers in our stack, from the external front-end applications down to the very back-end tooling used by our domain experts to generate data for our application, and that data itself.

Before I joined, I knew that the server was written in Kotlin and that the team use IntelliJ for development. As I've only scripted in a text editor in recent years I invested some time in getting some beginner-level skills in the new language and IDE with the help of YouTube videos and

I won't tell you that I didn't curse while doing it. Because I did, a lot. Why? For example, because of the new key bindings for the text editor, a new and complex environment wrapped around that editor, tons of helpful functionality with a high discovery cost and a steep learning curve, a new language with a new syntax, new concepts across the board, the tiresome wait for the compiler, ...

But I also won't tell you that it was a waste of time. Because it wasn't, at all. Why? For example, because I was able to check out and run our service in IntelliJ on my machine as soon as I started the new job; because I now do that under the debugger all the time; and because when I review the pull requests I have a sporting chance of making sensible comments or asking sensible questions.

Context drives my testing so I'll look for places to test that make sense given the environment, people, and work. PRs are a novelty to me and so I've been exploring whether in this role, on this team, for this product, at this time, they could be one of those places.

My initial answer is that, yes, it looks like reviewing each pull request as it comes through can be a productive activity for me. In just the last week it's spurred conversation about specific implementation approaches and general policy for our API, been a place that I can add unit and integration tests to work as it's going on, and even an opportunity for me to commit a fix for a bug that I've found while exploring the changes.

Now, some people might say it's not my job to write unit tests or fix bugs. I'd agree that I'm not (and don't want to be) a developer and, yes, that there's an opportunity cost to those activities which is higher right now because of my all-thumbs abilities.

But I'm using the tooling here in addition to the kinds of testing I would do anyway, to help me to test. Amongst other things,

  • I can exploit the unit test framework to investigate investigate a fix, and I can commit new tests that seem useful to preserve when I'm finished.
  • I can check out the in-progress branch and run it in the debugger to see which code paths are being followed for which inputs, or ask to see the value of any variable during execution.
  • I can use facilities in the IDE to search for similar code to the changes and see whether the fix has been applied there too, or understand why not.
  • I get a view of the coverage of our test suites and the friction around running them.
  • I get a feel for how our team likes to write tests and that helps me to add useful failing tests to my bug reports.
  • I get a view of the code, execution flow through it, components within in, local responsibilities and those subcontracted to libraries.

Pull requests are not universally loved but I'm not bothered about that for the moment. Right now, they are the way my team works and so they are a vector for me to deliver value through testing. And I'm exploring ways to do that.

No comments:

Post a Comment