Optimizely invokes its internal validators for the cart processing by default. This article describes how to skip this validation in scenarios where custom validation logic is in place, or we don't want UI to update the cart when viewing it.
Debugging multi-threaded applications might be challenging. Setting a breakpoint in a multi-threaded context might be run multiple times, making the debugging process difficult. However, JetBrains Rider allows you to make one simple trick to debug only a single thread for a certain breakpoint.
When it comes to debugging, there might be a case when the load of calls to the breakpoint is significant. Or, we want to log some data while debugging. In this case, it is useful to do not suspend the execution and evaluate the breakpoint condition and log the result (In JetBrains Rider).
Some testing classes may have a dependency to the ServiceLocator, so the dependencies are injected via property, for example. That makes class more difficult to unit test. In this post I will present how to write unit test for a class with dependency to ServiceLocator, with the real world example of Optimizely.
In some cases, there are classes with constructors that are impossible to mock with proxy-based mocking frameworks (such as Moq, FakeItEasy, NSubstitute, etc). In this article, I will present how to create a test for class that is impossible to mock.