28 Aug Software testing
In preparation for the [JavaScript Developers Conference](http://2017.jsdc.tw/) (JSDC 2017) for which I will be a [speaker](http://2017.jsdc.tw/speaker.html), I started going through my [GitHub](https://github.com/mlcheng) 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](https://github.com/mlcheng/freepee-web) 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](https://jasmine.github.io/) vs my very own Quantum.js's [testing framework](https://github.com/mlcheng/js-test).
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.
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!
Comments
Best luck on JSDC2017;)
: )
Thanks :^)