Lesson learned from writing a service for WebdriverIO

Introduction

At the end of 2019 I wrote my first service for a test framework called WebdriverIO and I must say that I have learned quite a lot when doing so. That's why I want to share my experience with you so that hopefully you learn something from it too.

The idea I had was to create a service that would download, start and stop a piece of software called WireMock. Now I am not going into details about what WireMock is or does but in short it is an application written in Java that allows you to mock/stub your internet traffic.

Why?

I was faced with WireMock during my job and realised that there's no service that does this. At the same time I thought to myself, how hard can it be?

Well, the challenges that I faced weren't really the type that I would normally face so it was a good thing that I started this little project of mine.

Research

I already had an idea of how to create a service locally that I could use but to create a npm package and use that is something different entirely.

To get a grasp of the things that would be required I started researching already existing services. For this I choose to use wdio-chromedriver-service and @wdio/selenium-standalone-service which helped me tremendously to understand how I could create a start.

For example I noticed that both services used the spawn function that is provided by the child_process module found in NodeJS. I tried to use spawnSynch function first because I had to wait for the process to start and I thought this was going to help me with that.

Instead of helping me it turned out that it would hang until this process was terminated, which is not what I needed. So I figured that I had to use the async version and deal with that issue in another way. After a while I actually got things working but what I didn't know yet was that while it seemed like everything was working in reality it wasn't working at all and I was just lucky.

The code and the problem

So what does the code actually look like? Let me show you what I had going.

Here you see that the process is spawned and it is assigned to a property called process. This action was done async which means that my tests where started as soon as this action had been triggered (note: triggered yet maybe not completed). In this case the action went so fast that during testing this, it worked each time.

But as with all software it is good to be thorough when you write and test your code which is how I found out that I was just lucky for not running into issues during my testing phase.

Approach when there is no obvious answer

Even though I tried some solutions that might or might not work, I could not come up with a simple solution that would ensure that the service would be started though not be blocking the thread.

So after a while I stopped looking for solutions like promisify and decided to look at other software and I started with some already existing services. After some digging I found out that the wdio-selenium-standalone-service also faced the same challenge that I was facing and I quickly looked at the solution that was used there.

I could not believe my eyes when I saw the solution though, sometimes things are way easier than you think. You just have to simplify the problem and/or take a step back and approach it from a different angle!

The solution

If all that I did was start a program that runs on a specific port, then why not simply wait until that port is taken? Like i said, the solution might surprise you!
This goes to show that it’s good to sometimes take a step back, people sometimes say that going for a short walk is enough to clear their head and approach a problem from a different angle.

So what does the final code look like?

I installed a package called tcp-port-used and imported their waitUntilUsed method to wait until the port is taken (it waits for 10 seconds with an interval of 100ms). Easy right?

Takeaway

I hope you have learned that when you are stuck that the solution might be easier than you think. Taking a step back to approach it again later can be a good thing and I hope you now feel more comfortable in doing so!

Hopefully my story inspires you to create your own piece of software some day.

If this has been helpful to you, let me know in the comments below!

Cheers,

Erwin