![]() You will probably just re-run the test suite and if it passes, you are good to go. When it fails, you have no idea were to start fixing it. Write too many tests, make them very entangled and any minor change in your application will take a lot of effort to make all tests pass again. Even if you are able to write proper tests, throughout the lifespan of the product/project you are working on, requirements will change, new scenarios will appear. And extra time is something that your clients or the business people in your company will not give you so easily.Īin't nobody got time for that! (Photo by Aron Visuals on Unsplash)Īnd it gets worse. However, after if you have done this for some time, you realize that writing good tests are as hard as writing production code. If something is hard to test, there is probably a better way to implement it. The biggest win when writing tests first is that it guides you through the design of the code you will write next. This is not necessarily a bad thing as different problems require different solutions, but this still intrigues me a little.Īs a ~most of the time~ TDD practitioner, I have learned that the main reason we write tests it not to assert the correctness of our code - this is just a cool side effect. I think every single time I start a new project - professionally or just for fun - my ideas on how I should test my code change. I have created a repo implementing the ideas above.Īs a Software Engineer, I am always finding ways to get better at my craft. The strategy when testing thunks is to setup the store, dispatch the thunk and then asserting whether it dispatched the actions you expected in the order you expected or not.Because of the way thunks are structured, the only way to test them is by testing their implementation details.Here you can use stubs, spies and sometimes mocks (but don't abuse mocks).Only after the thunk is called is when we will have the side-effects we need to make our application work. Dispatching thunks doesn't have any direct effect.Your slice is somewhat equivalent to a pure function, which means you don't need any mocking facilities in order to test it.Selectors and action creators should be boring, so they won't require testing.Using selectors gives you the granularity you need to run simple assertions.Avoid assertions like toEqual/ toDeepEqual against the state object, as they create a coupling between your tests and the state structure.Use action creators and selectors, without having to write tests targeting them in isolation. Tests should interact with your redux slice same way your application will.As they are tightly coupled with each other, isolation gives us little to no value. There is no point in testing reducers, action creators and selectors in isolation.Unit tests should interact with it as a whole. The smallest standalone unit in Redux is the entire state slice.When testing Redux, here are a few guidelines: This article was originally published in my blog. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |