#anithings

[code-n-mocha]

Testing: Mocks 2

It's nice to have tools that lets you do what you want. In this case, I read about how Jest create mocks and was wondering if Mocha had something similar. Nope, doesn’t have. So sad.

BUT! Good thing is good, webpack keeps surprising me and there is a plugin (inject-loader, https://www.npmjs.com/package/inject-loader) that lets you inject mocks into your components. This way you don’t have to modify your codebase (you should never modify your code for the only purpose of testing).

Here is an example:

This is the dependent class

This is the test class:

As you can see, I needed to import the Inyector class, tell him what class needs to wrap and --as an option-- it can be specified what dependencies will be mocked. In this case, I just wanted mock ‘components/Monster’.

Last thing, I had to access the Inyector’s `default` prop (who is the mocked class). IDK why you need to do that, but is how the Inyector function returns the data.

Once I ran my tests, it was printed `hello ^o^/` in the console! Wohoo! Now I have mocked classes inyected into your unit tests.

See you next time!

[code-n-mocha]

Testing: Mocks

Recently, I was learning pixi.js, react, testing and es6 (through tutorials, courses and stuff) and, wanting to put my knowledge into action, I started to write a pixi.js components (I'm trying to do simple things but well written, with ES6 modules, plenty of test and webpack (I hate you webpack, but I love you, but I...)).

One thing I faced when writting unit tests for pixi.js components are Mocks. How I could make easly to test my so-simple-and-ugly (it has no style) Name component? I would have to care about:

- Instanciate PIXI renderer, - insert my text component into it, - and simulate the events, because it has events listeners.

But that would break the "unit" of unit testing, and would make them more hard to write. So, thinking what I needed to test, I wrote simple js objects who have the "same" input-output as the real objects, and inject them into my Name component, resulting in an easly and clear tests.

That way, my tests are faster (I don't need to instantiate the whole environment), easier to understand (mocks are simple, and tell you about what input expect and what output they give), and let you check if you calls them or not (making assertions into them).

In the above example, I’m simulating the mouse over event and the collision system provieded by pixi.js. In the first one, I only added the things that would make my code crash, like the `data.global` property, and the `preventDefault` function. In the seccond one, only returned what it would have been returned the real `processInteractive` method.

In this one, the interesting parth is the `willUnmount` method. As I wanted to check that my Renderer component was propagating the unmount as expected, I made an assertion about that. That was possible because I used a mock.

How about you? You mock your external components? How do you test with pixi.js?

See you.

[code-n-mocha]

How to make eslint understand your webpack resolver

When developing with webpack is common to add your source root folders into his resolver, so you can access your dependencies without caring about relative path.

This is excelent as is, but if you're using eslint and you want to check statically if you didn't have a typo, it'll throw false negatives because eslint doesn't know about webpack and his resolver by default.

So, what we do?

We need two eslint plugins:

npm i --save-dev eslint-plugin-import eslint-import-resolver-webpack

Add this to our .eslintrc file (mine is in YAML extension because is simpler than the JSON version:

settings: import/resolver: webpack: config: 'eslint-webpack.js'

The main point is the eslint-webpack.js file. In my case, appart of my webpack files (who are inside of dev-tools/webpack folder, I have this one in my root proyect only for linting porpouse. This is because my webpack files has dependencies and the eslint-import-resolver-webpack doesn't work if it has a lot of them.

And Fill our eslint-webpack.js file like this:

module.exports = { resolve: { root: __dirname, alias: { app: 'app', applicationStyles: 'app/styles/app.scss', }, extensions: ['', '.js', '.jsx'], }, };

Add as much aliases as you want. The root with the alias properties are used by the eslint plugin to know your correctly paths.

In my app/app.jsx file I have this two dependencies:

import Main from 'app/components/Main'; // App css import 'applicationStyles';

And eslint doesn't say anything. Instead, if I would have had import 'applicationStylesWrong'; it would have complained about.

BUT, this approach has one downside: you'll have duplicated resolve information (in your webpack file and eslint-webpack file). Also, doesn't work if you use the "modules" approach: modules: ['app'], instead of "alias" attribute.

See you!

[code-n-mocha]

Yes! I finished this [Pixi tutorial](https://github.com/kittykatattack/learningPixi).

My code: https://github.com/LucianoGraziani/pixi-learning.

Next step: make a better synergy with react.

[violetatlas]

Omg, why did i read all that this late? What the eff kind of an ending was that? Cameron, I am never letting you talk me into anything anymore Why Nezumi, why? Too much too soon, I haven't recovered from last week yet!