What I have learned from the Kent C. Dodds testing JavaScript course

The strange thing is happening when one is gaining more experience – it is harder to identify or to find what new to learn. It definitely depends on the width of the area, as some things can be learned in a few hours, and for some, even a few years are not enough. And with this more broad areas it is easier to experience this phenomenon when even though you do know that you do not know everything, it is hard to identify what you do not know.

I have no idea what is the magic recipe to cure this. One of the ideas, that I try to cultivate it my mindset, is that even source is explaining some sort of the things, that I already knew still can learn something new and interesting if I am attentive and curious enough.

At the end of the previous year, all engineers in the company where I work were “attending” (as it is all was happening online and async it is in quotation marks) JavaScripts testing course created by Kent C. Dodds.

Below are some of my notes from this course. Due to the phenomena, that I have described above, they are quite fragmental, as contain only things that were new to me, or about which I got curious.

  • Why we have .eslintrc and .prettierrc?


  • Why npm run prettier -- --write – what is staying for -- ?

https://stackoverflow.com/questions/44743626/whats-mean-of-npm-scripts-two-dahses. Used with npm only

  • “Make flow happy” :TM: Before taking this course, I thought that this phrase is popular only inside our company when we referring to adding some code only “to make flow happy” 🙂
  • Husky needs to be installed to run git hooks? Is it necessary, isn’t this from the box with git?

Doesn’t look like it is necessary one https://github.com/typicode/husky, https://git-scm.com/docs/githooks. It actually doesn’t. I would love to hear this more specifically in the video

  • Lint-staged package to run linter only over files that have changed
  • What is monkey patching?
  • jest.fn. Used to validate something specific about function, for example, like with how many arguments it was called, or how many times it was called
  • The .spyOn method will replace the getWinner on utils with an empty mock function.
  • with jest it is possible to mock the whole module, that was imported in the test file
  • jest allows eternalizing mocking for utils __mocks/{name of the file that you want to mock}.js
  • You can run npm run test or nom test or npm t it is all the same?

I haven’t known, that tree shaking is not only the idea, and is already actively utilized

  • if you do not need jest to use browser env, you can set up it not to use JSDOM, it will bring better performance to your tests by flag --end=node or in jest.config.
  • we are mocking CSS imports with empty js file in node? https://testingjavascript.com/lessons/egghead-support-importing-css-files-with-jest-s-modulenamemapper????
  • identity-obj-proxy – to import CSS for example properly
  • git diff HEAD^ HEAD in the terminal will give the difference between current commit and previous commit in terminal
  • I should use more snapshot functionality that is included in Jest
  • Jest has built in the capability of serializing and formatting DOM nodes, this will allow better identify the difference between outcome value and snapshots.
  • There is a possibility to write custom serializers for Jest
  • We can start debugging from jest test env, and debug from Google Chrome. For this, we will need to have a special script for node to run jest

"scripts": { "test:debug": "node --inspect-brk ./node_modules/jest/bin/jest.js --runInBand", }

  • not every line in our program is equal :TM:
  • there is a possibility to configure watch mode (examples:

watchPlugins: [ 'jest-watch-typeahead/filename', 'jest-watch-typeahead/testname', 'jest-watch-select-projects', ]

What I liked in courses:

  • help with setting best practice in project and making it to the automation level
  • explain not only how testing libraries can be used, but also logic inside the functions and methods in the test libraries, with recreating it small analogies – can help a lot, if you want to get familiar with it, for example, to start contributing to some library

What can be improved in courses:

  • We end-up with understanding, that courses better to be done in reverse order to which they were present on the page
  • There was some flash of another screen every time I was accessing a new course – no idea what was on it, as it was to fast
  • Would be nice to have some tasks that can be done, and are related to what was explained in the course, so one can have their hands dirty easily, and end up with more practical knowledge
  • I would love some overview on the start of the course – like to understand what this course will be about – yes, I can check the list but would be lovely to have like 30-sec video recap, of what I will learn
  • I would love more encouraging failing first approach, so to see that we are actually testing something

General conclusions

If you are planning to watch this course, define your purpose before going through this course. What can be a purpose – create an action plan of how to improve testing in your codebase, introduce new types of tests to your project, etc.

If you have found a spelling error, please, notify us by selecting that text and pressing Ctrl+Enter.

Olena Sovyn
Senior Software Engineer (London, UK). I ❤ React, Redux, lodash, React Storybook, and functional programming overall. Always open for learning something new

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Spelling error report

The following text will be sent to our editors: