[Previously] I was talking about combinatorial complexity of integration tests in multicomponent systems, so let me remind. Let's build a simple system with only 3 components inside. It can be three independent modules and we want to provide some communication between them (message passing good enough for the purpose of the example) So we have 3! = 6 possible configuration to test. Before going deeper lets see how Quicksort fights a combinatorial complexity.

[Quicksort] reduces complexity on each pass of a given input. So far so good. Let's imagine example with 10 elements. How many possible permutations do we have? you are right: 10! ~= 3,6 * 10^6. So on the first pass the complexity will be reduced: 5!*5!, on the next pass it will be further reduced till 2!*3!*2!*3!… after logn times we will have 1!*1!*1!...1! = 1 possible position, and our given input is sorted. Gotcha. (attentive reader can mention about worst case scenario of quicksort, but lets discuss it someday) Coming back to our example…

[Simple task] So we have a task to pass a message through our entire system, our three modules system. Let us not reinvent the wheel and call our modules A,B,C. Just keep in mind 3! possible configurations, we need to build a system with only one allowed configuration: A -> B -> C. Easy. Lets add a feature and allow module C to send a message to module A — we are getting two more configurations: B->C->A, C->A->B (some people can recall terms permutations, combinations) In practice we get circle structure, which is very useful to be honest, and first structure called linked-list. If we continue to play around and allow modules to send message back we end up with bidirectional linked-list. We will discuss structures a bit later, lets come back to our three modules system and add one more module B2.

[Nature of a bug] So we have a system with four modules: A,B,B2,C. As you can see B and B2 are almost the same. So we have 4! possible configurations and the task to send a circular message. The same guy can easily add one module to the system and to conclude that there is only 4 possible configurations, because previously there were 3 and he or she added only one more module. Almost. The truth is that we have 4 more configurations (B and B2 can be swapped), in total 8. Programmer covered four, other four paths are left in a wild. Should we blame him or her? who knows, lets better look on tools which developer use to fight with complexity.

[Tools] They are: if statement and feels like a god == to use unconstrained systems. For many of us just much simpler to build a system without any structure and constraints. Full stop. Don't lie to yourself, we want to feel max flexibility that's why we choose javascript, remember? You can say OK, its all good and maybe true, but what about React? Lets go further…

[react] Remember the part where we discussed structures? me too. So when one guy starts to write an integration tests all what he or she has it's a number of components in the system. So to cover all paths in the system, developer needs to cover factorial! configurations of the system! How can we do better? Hint: lets provide a bit more information for the guy who has already written 10! tests. If we could somehow provide a structure to a poor guy, his or her life would be much simpler. We just need to expose a (react tree) structure to the library (jest). Then library by comparing trees structure (old/new) can give you what's changed. Profit. Not very big one, but very promising one. And there is more, not for today but will be more in the next topic.

About integration tests