A flight controller is the brain of any multirotor; it is the most crucial component. When my Alien 560 quadcopter fell from the sky, I figured it happened because its flight controller malfunctioned mid-flight. Therefore, when I decided to build a new drone and started choosing the components, a flight controller was the most difficult choice to make.

About a year ago Hobbyking was having one of their “Flash Sale” events. During a few days, they dropped prices on a few hundred items. An online shopaholic in me couldn’t miss it. I meticulously studied the offerings until I found something worthy of my attention and money. That was a Jumper 218 Pro racing quadcopter, almost ready to run. A bargain at a just a bit over $100! I just needed to add an RC receiver.

I received it a few days later and, as it often happens, put it on a shelf for a few months. From time to time I would take it off the shelf, hold it in my hands, make a few plans for it, and then put it back. At the time I was still concentrating on building my Alien 560 quadcopter, and the smaller drone was a distraction. The “project Alien” appeared to be never-ending. Every time I flew it, I saw a way to improve it. I would disassemble the copter and work on it for a week or two. Then put it back together, fly it, and then dismantle again. Only when I crashed the Alien, I decided to take a break from it and turned my attention to the Jumper.

There is a subtle issue for which, unfortunately, neither ES6 nor proxyquire provide a solution. It is well described in this stackoverflow.com answer. So far in the previous articles of the series, the dependencies we were mocking were in a separate module from the code we were unit testing. But what if they were in the same module?

In part one, I wrote about mocking ES6 module dependencies using the ES6 native import * from construct. It works mostly fine. However, you need to be aware of a potential issue:

• You need to import modules to mock them, which means that those modules will be evaluated. That may be a problem if you don’t want the code in this modules to be executed.

Another method I found to work well is using proxyquire.  It is one of many libraries aiming to streamline mocking dependencies to simplify unit testing.

Not so long ago I faced a problem: I needed to mock ES6 module’s dependencies for unit testing. The reason for mocking dependencies in unit tests is the following: when I write a unit test, I want to test the functionality of a single unit of code, hence a unit test. However, if a module has any dependencies, those dependencies need be satisfied. That may mean importing and executing code in other modules. As a result, the unit test loses its purity – the test results will depend not only on the module I’m focusing on but also on the other code my module depends on.