Test-Driven Development in JS with Acceptance Tests

[@Richter12]

I love the explanation, extremely high quality coding and examples. You gave me a lot of context on testing I really hope you keep doing all these videos.

[@esc120]

Hi! Thanks for the awesome content! 😀 I just found some problem in the code so I put them here: 17:17 Do not use Array.map for side effect. Use Array.forEach if you are not actually mapping things. 25:33 Do not add unknown attributes on standard HTML elements. Use data-* for custom data attributes instead. 29:46 Array.slice is using shallow copy, so you are still mutating the inner object.

[@branvandermeer]

Good points, thanks for the codereview! A second pair of eyes is always a good idea :)

[@ermakamre]

Hello, thanks for the video! Some questions/notes: 1) Why there are no tests for the react components AddTodo/TodoList, were they developed without TDD? 2) Injecting initial state to the App looks like a cheating, there is no such simple approach in real apps. How would you deal with app that takes initial state from the server? 3) Should data-testid be unique on the page? 4) Introducing done field and not updating the state in all existing tests also looks strange, treating done as optional is questionable approach. 5) Does is it worth to execute all tests including the potentially slow acceptance tests every time while working in the inner loop of TDD? 6) Why not to run the tests inside the IDE?

[@branvandermeer]

1) First because they weren't the focus of my video, but also because they're too simple to warant a test I would say. If you look at the AddTodo component, there isn't even any branching, just html rendering. What would you even test? The actual logic is in the reducer. 2) I hoped to make a more realistic example without having a gargantuan codebase. You can look at other design patterns and frameworks which promote centralised state management. This was introduced with Flux, it's now in the more modern Redux, MobX and GraphQL/Apollo. Yes, in larger apps not in the root, but even then, its about passing the `state` and `dispatch` via either props or the react context api (not the only solution ofc, but the most popular one). And the elephant in the room is ofc testing: now its easy to inject, so to make it testable, I even prefer a (semi-)centralised state management solution. 3) Not sure. On the one hand, anything called "id" (as-in "identifier"), implies uniqueness for me. On the other hand, I would like to select multiple sometimes, so maybe I should start using a data-testclass analogous to html's id/class attributes. 4) I actually prefer my objects to be open for extension, and closed for modification (Open-closed Principle). It's fine that the object contains more properties than what the tests need. I do this all time, because it makes sure I don't tight-couple my tests to the full object specification in this way, but instead my tests only access the properties they need. (I also dislike TS a bit for this reason.) As another example; in the last 2 tests in this code: pastebin.com/hutbAgqr - I've explicitly chosen to only expect() the 'from' and 'to' properties, thereby loose-coupling myself to the object. I don't have to change all my tests all the time as my code evolves, there's no added value in an exact object match for those tests, they're there to mitigate a different risk. If they were tight coupled, it would also give me more false-negatives, they would fail for the wrong reason. 5) That becomes a question of cost/benefit ratio. If your acceptance tests are more towards end2end tests then definitely not. If they're slow, also skip them. In general, it's good to have the capability to run just 1 test suite or something. (I'm not a fan of end2end tests at all, they're often not worth their money. Many end2end cost more time and headache, they're not catching bugs but they are often failing when they shouldn't fail.) 6) Just preference. The terminal inside VSCode is less performant and configurable for example (I automate and configure a lot). In addition, I ran jest without babel in nodejs with es-modules, this requires experimental flags which weren't accepted automatically by the jest extension in VSCode. I could have made it work probably, but I chose to spend my time on a better a video :)

[@havefun5519]

Detailed explained