In preparation for the JavaScript Developers Conference (JSDC 2017) for which I will be a speaker, I started going through my GitHub projects again... In particular, I noticed my tests were not as good as they could have been, especially for projects like Free Pee 2.0 where I actually only test the API. This is a direct result of my stubbornness in refusing to use third party libraries for something I could write myself. In this case, I'm talking about Jasmine vs my very own Quantum.js's testing framework.

In Quantum.js, tests were fairly crude and straightforward. One unit, one assertion:

Test(...).expect(something).toBe(something);

Then I wanted setups for the tests.

Test(...).do(() => {}).expect(something).toBe(something);

Then I added method observers - because Jasmine's spies were so awesome. Things started piling on.

Test(...).observe(some, 'fn').do(() => {}).expect(some.fn).toHaveBeenCalled();

Quantum.js's tests run asynchronously. That's because the setups may involve a Promise. The tests also run in the global scope. Which probably was not the best choice, but with no experience in testing, I didn't really know what I was getting myself into when I started the library ¯\_(ツ)_/¯ So now with observers in that mix, we just end up with horrible side effects everywhere.

Quantum.js testing side effects

Yeah. It's probably time to either refactor Quantum.js so that tests run synchronously, or just start using Jasmine. Knowing me, I'll probably start with that refactor. I fully admit that I probably have no idea what I'm doing or if synchronous tests are even a good thing, but I guess we learn by making mistakes!

August 28, 2017 | 3 comments

Comments

Best luck on JSDC2017;)

MM | August 28, 2017

: )

lynn | August 28, 2017

Thanks :^)

Michael | August 30, 2017
© 2018 Michael Cheng
made in Taiwan