Retries are a fact of life in testing. That file you are trying to read might be temporarily locked. The network connection could momentarily break. You may need to keep pinging a server for status until it returns the result…
Testing down low
In the last post, I discussed high-level testing of a simple distributed service. Now let’s look at the bottom of the stack. What are good candidates for testing at this level? To name a few: Basic functional/algorithmic correctness Unit/module cohesion…
Testing from up high
In the previous post, I introduced a simple distributed service and some considerations that might drive a test planning effort. In this initial drill down, I will take a look at the tradeoffs of testing this system “from up high”…
Testing at the right level
A large-scale distributed service is deployed to a datacenter across hundreds of machines. The basic topology is as follows: Consider the following scenarios and requirements: The service should respond with an error if a client requests a nonexistent resource. The…
Programmatic trace analysis with Tx
One of the benefits of ETW trace files is that they are fully structured. That is to say that they contain well-defined and strongly-typed data payloads, in contrast to raw text log files which only contain message strings. While this…
Using alerts to drive a load test
In the previous post, I promised to show a practical use case for performance alerts. Today I will make good on this promise and show a complete code sample on how to drive a load test using alerts. Imagine a…
Real-time trace sessions with TraceEvent
ETW log files are great for post-mortem debugging and analysis. But did you know that you can actually process ETW event streams in (near) real-time without log files at all? It’s true! Real-time event consumption has historically been accessible only…
Designing for fixed concurrency
Consider a simple load test which is trying to maintain a constant stream of parallel requests against a server. That is, at any given moment the server should be handling, say, 100 concurrent requests. The exact number is not important,…
Async exclusive lock: integration test
In the previous post, I introduced my ExclusiveLock. In the typical TDD style, I ended up with a correct single-threaded implementation. However, as soon as I added parallelism and exception tracking to the basic integration test, I began hitting exceptions…
MemoryChannel integration test
In a previous post, I discussed the concurrency issues with the initial MemoryChannel implementation and how unit tests were insufficient to uncover them. I came up with these basic requirements/invariants to guide my integration test design: Data from separately sent…