Last modification on 2026-05-09

In 2016, Christoph Pojer (at the time a Facebook developer) introduced Jest’s snapshot testing to the world. In a talk with Kent C. Dodds¹, Pojer posed a question that has influenced modern front-end development: “What can we do to make it low effort to write unit tests?”

The problem Christoph identified was real: developers find writing unit tests tedious. His solution was to automate test writing and make it easier for developers. But in reality, this approach made things harder because the generated tests are more brittle and less maintainable. By choosing “easy” over “simple,” snapshot testing didn’t solve the problem that developers need to understand when writing unit tests at scale—it made the problem worse.

Brief Overview Of The Robustness Principle

The robustness principle, also commonly known as Postel’s Law², states: “be conservative in what you do, be liberal in what you accept from others”. Although Postel briefly mentioned the robustness principle for designing internet protocols, programmers have adopted and extended it across many programming contexts—from function design to data processing to API contracts. Consider a Javascript function that calculates the total price of items:

function calculateTotal(items) {
    return items.reduce((sum, item) => sum + item.price, 0);
}

This function is fragile—it crashes if you pass it anything other than an array with a reduce method. It will fail with Set objects, array-like objects, or iterables. A more robust version accepts what it needs liberally:

function calculateTotal(items) {
    let sum = 0;
    for (const item of items) {
        sum += item?.price ?? 0;
    }
    return sum;
}

Now it works with arrays, Sets, or any iterable, and items can be undefined or missing their price property. This example demonstrates how the robust version is “liberal in what it accepts” while remaining “conservative in what it does” (calculating a sum).

In practice, you’d want to restrict this to only objects with a price property. Being too liberal in what you accept does carry security implications worth considering. RFC 9413³ and research in language-theoretic security (LangSec)⁴ by Meredith Patterson have shown that overly permissive input handling can introduce vulnerabilities. For instance, if the function recursively calculated prices in nested objects without depth limits, and the input came from an untrusted user, an attacker could construct deeply nested structures to trigger a denial-of-service attack. In this context, it’s typically safe for input objects to contain extra properties that the function simply ignores.

To restrict our function to only accept objects with a price property, we could use TypeScript to check for us.

function calculateTotal(items: Iterable<{ price: number }>) {
    let sum = 0;
    for (const item of items) {
        sum += item.price;
    }
    return sum;
}

Robustness in type theory extends well beyond simple input validation to encompass more sophisticated concepts like contravariance, where functions are deliberately designed to accept broader, more general types than strictly necessary for their immediate implementation (being liberal in what they accept as input). This flexibility allows functions to work with a wider range of arguments while maintaining type safety. The “L” in SOLID—the Liskov Substitution Principle—formalizes this fundamental idea of robustness at the type level through the concept of behavioral subtyping. The principle states that objects of a superclass should be replaceable with objects of a subclass without breaking the application, ensuring that derived types extend base types without altering their desirable properties and behaviors.

Snapshot Tests Violate The Robustness Principle

In software testing, it helps to think from a meta-programming perspective: the code is your input (or data), and the test results are your output. The goal is to write conservative tests that liberally accept different implementations, so software modifications don’t unintentionally break existing tests. In other words, your unit tests should be robust to change. A test should only fail when the specific behavior it checks is actually broken.

Snapshot testing achieves the exact opposite. Because a snapshot asserts the entire output of a function or component, it’s inherently brittle. A single, irrelevant change to any property breaks every test that depends on that function.

Consider a function that returns user data:

function getUser(id) {
    return { id, name: "Alice", email: "alice@example.com" };
}

With snapshot testing, your test captures everything:

expect(getUser(1)).toMatchSnapshot();
// Snapshot: { id: 1, name: "Alice", email: "alice@example.com" }

Now add a createdAt timestamp to the user object:

function getUser(id) {
    return { id, name: "Alice", email: "alice@example.com", createdAt: "2024-01-01" };
}

Every snapshot test breaks, even though the core behavior (returning user data) hasn’t changed. If you have 10 snapshot tests using this function, you now have 10 failing tests instead of zero.

The robust alternative uses targeted assertions:

expect(getUser(1)).toHaveProperty("name", "Alice");
expect(getUser(1)).toHaveProperty("email", "alice@example.com");

These assertions remain true when createdAt is added—they only fail when the specific properties they care about actually break. I’ve led teams and scaled projects with hundreds of unit tests, and I’ve learned this: if developers don’t follow basic principles like robustness, adoption of unit testing will fall apart. Does that mean instead of writing 10 unit tests, you’ll need to write 20 and type more? Yes, but that’s the price of building something simple rather than easy.

Easy vs. Simple: The Design Trade-off

In his talk, Pojer identifies the manual creation of assertions as a point of friction: “You try to write a test and you have this object and you try to match [it with] toEqual… how can we make this easier?”

This approach highlights a common tension in software design: prioritizing immediate ease over architectural simplicity. While generating and updating a snapshot requires very low immediate effort, it tightly couples the test to the entirety of the function’s serialized output. In contrast, a simple test relies on targeted assertions that verify specific invariants, decoupling the test suite from irrelevant structural modifications.

Because snapshots assert against the complete output, they frequently fail due to benign changes. When a test suite generates a high volume of false positives, developers can experience alert fatigue. This often leads to a routine of automatically updating the snapshots without strictly reviewing the code modifications, ultimately degrading the reliability of the test suite as a functional verification tool.

The Limitations of UI Snapshots

A common rationale for maintaining snapshot tests is their application to UI components⁵⁶. However, a user interface is a visual output derived from the complex interplay of HTML, CSS, and browser rendering pipelines. A Jest snapshot strictly captures the serialized HTML structure.

Because the testing tool does not evaluate the rendered output, evaluating HTML markup is an unreliable method for verifying visual correctness. An updated CSS utility class will fail a snapshot test, but inspecting the resulting HTML diff provides little assurance to developers that the visual rendering remains intact.

Test objectives should dictate the tooling. If the goal is to verify component semantics or accessibility attributes, explicit assertions remain the most robust approach (e.g., expect(button).toHaveAttribute('aria-expanded', 'true')). Conversely, if the objective is to guarantee visual consistency, the correct technical solution is Visual Regression Testing, which evaluates actual pixel renderings.

Ultimately, snapshot testing occupies an ambiguous technical space: it lacks the targeted precision of a unit test and the visual accuracy of an end-to-end rendering test. By archiving the current state of an output rather than defining its required functional constraints, snapshots record what the data is rather than what it must be. Transitioning away from snapshots requires writing explicit assertions, which demands more upfront effort but yields a more resilient and meaningful test suite.

Last modification on 2017-03-01

You may have tried googling this question to end up coming short or, even worse, be more confused than you initially were. That’s because people interpret the term “blockchain” in different ways. Like the word meme…

…meme was coined by Richard Dawkins to represent a “social gene” — a meaning that only exists within social constructs. Winking in Ireland is a meme for being friendly. It’s socially passed down from one person to the next like a gene, but it was not passed down completely, which is why it means something different — promiscuous — in the US. So when you’re in the US, don’t wink at strangers (wink wink).

Today, the social web has extended the term “meme” to mean any funny joke. The term blockchain is no different. It means something different depending on which community uses it.

That causes a lot of confusion and has made it the one question that people at work in IBM’s Bluemix Garage ask the most after several new Garage locations were announced because of the highly demanded consultancy for blockchain-as-a-service. The service is powered by the open source project, Fabric, IBM’s blockchain merged with digital assets, and is now the leading incubation project for Hyperledger.

I’m asked this question a lot because I’ve been in the Bitcoin loop for years now and have founded a Bitcoin startup before joining the Garage. Luckily, Hyperledger is very different from Bitcoin and much simpler to understand because of its centralized security model.

To put the question to rest, my observation — from being part of the Bitcoin community, interested in what Ethereum has been up to, and listening to some leaders of the Hyperledger project explain blockchain to large crowds of people — is that all definitions of blockchain cross at one point. That point most closely resembles Haber and Stornetta’s timestamping solution (circa 1990) as referenced in Bitcoin’s whitepaper.

Generic Use-case Scenario

To understand the timestamping problem, here’s an example scenario:

• Alice owns property X and wants to transfer ownership to Bob.
• Alice digitally signs a contract — stamped with the date and time — that transfers ownership of X to Bob.
• Bob can prove ownership of X since the date and time on the contract.

The problem is that nothing stops Alice from digitally signing a second contract with an earlier timestamp to transfer ownership of X to Charlie. Charlie can get the authorities involved and claim Bob stole X from him. Bob shows his contract, and now the spotlight is on Alice. Why did she sign two contracts? Alice can invent a story that she didn’t sign Bob’s contract: he stole her private key and signed the contract himself.

So to whom does X belong? Alice, Bob, or Charlie? No one outside the negotiation knows, not even the authorities, so it can’t be settled in court. That makes Alice’s timestamp useless.

That’s the problem. The timestamp must come from a trustworthy legal entity. This is the same problem that cryptocurrencies, like Bitcoin, have faced for decades and is commonly known as the double-spending attack.

TSA: Timestamping Authority

The easy solution is to use a third-party service, known as the Timestamping Authority [TSA], that everyone can trust, like a bank, to sign and timestamp contracts. Now, Alice can digitally sign a contract that transfers ownership of X to Bob and go to the TSA to have the contract signed and timestamped with the current date and time.

Bob can then accept the contract since it was signed by the TSA. Alice can sign a second contract to transfer the ownership of X to Charlie, but the TSA will not timestamp the contract because property X belongs to Bob, not Alice. That solves the problem…sort of.

The problem with that solution is that everyone trusts the TSA. This leaves the TSA with too much authority to sign and timestamp contracts. If the TSA somehow benefits from screwing over Bob and taking sides with Charlie and Alice for capital-gain reasons, Bob will get screwed just like in the initial scenario. Trusting the TSA doesn’t guarantee a trustworthy system.

Haber and Stornetta’s timestamping proposal helps reduce — not fix — the problem, by minimizing the TSA’s authoritative power. Instead of the TSA signing and timestamping contracts, that authority is left to the parties of the contract, greatly reducing the TSA’s privilege. The TSA only acts as a ticking machine that sends out a signal at an interval to aggregate a bunch of contracts and transparently broadcast that information to an open network of witnesses.

You can’t simply trust a random person, so to join this network of witnesses, or let’s call it “the gang,” you have to be invited. That means having a registration system and identifying each member of your gang. It can just be your friends or your business colleagues. The larger the gang, the better, since it makes the gang more distributed. So, let’s say the interval is 10 minutes. During those 10 minutes, the gang will spend time collecting all hashed documents that have to be timestamped.

Hashed documents?

Hashed documents. Say it with me. Hashed documents. If you want a blockchain, you don’t want a weak chain. You want a strong chain! Yeah! Think of it as a physical chain. What kind of chain do you use to tie your bike? A plastic one? I don’t think so. You want a steel chain that is hard to break. The same goes for blockchain. Hashing is the steel. You don’t need to know how it works, but what it does.

A crypto hash function takes a text of any length and randomly creates a fixed-sized text called a hash. That’s it. If you take a legal document text and hash it, it will produce a short random text. Hashing is magical for several reasons you should know:

1. It’s impossible to get any information from the legal document with only the hash, so you can safely share the hash with anyone in the world and know that the chances of Earth getting struck by an asteroid are significantly more probable than someone recovering your document from the hash.
2. It’s impossible to generate the same hash with different documents, so the hash is the identifier of the legal document.
3. It is random. Changing a single character in the legal document text will generate a completely different hash.

Timestamping

Okay, now that you know hashing, you’re halfway to knowing how blockchain works! Yay! Stay with me! Back to how timestamping works. When a client wants to timestamp a legal document, the client hashes the document and gives the hash to the gang. The gang continues to collect all hashed documents until the interval is up.

When the interval is up, all hashed documents are hashed together one by one to represent all documents collected as one “block”.

The same happens at each interval.

But the blocks don’t stand alone. The block hash is hashed with the previous block’s hash. So the hash of one block depends on the one before it, and the one before it depends on the one before that one, and so on. Because of the hashing properties I mentioned, this literally ties all blocks together, creating a chain.

That builds up a chain of blocks aka. blockchain.

Changing a single character in any hashed document or adding a block in the middle of the chain will require changing everything in the current block and every block ahead of it. That is a very important tamper-proof property that blockchain provides and is one of the biggest selling points anyone would make to you. Think of blockchain like a timeline — the past should not be changed.

In that sense, the timestamping solution is misleading because it never specifies a time but the relative time¹. That’s the most important matter — order preservation. That is sufficient to help poor Bob not get screwed like last time.

Security of blockchain

This is my favorite topic of all, and I can spend hours talking about it, but I’ll just get to the point. I lied earlier. Blockchain is not 100% tamper-proof. In other words, it can be tampered with. It’s technically tamper-evident. If something changes, the hashes will change. As I mentioned earlier, changing a single character in any hashed document or adding a block in the middle of the chain will have to change everything in the current block and every block ahead of it.

One question I skipped was: how does the gang agree on who adds the next block to the blockchain? Another way to phrase it: What is the consensus?

A simple consensus could be a roll of the die. Whoever in the gang gets the highest roll gets to add the next block. That’s just an example. You can get creative and come up with any algorithm you think works best. What matters is that the consensus is fair and doesn’t benefit anyone.

But when there is consensus, there needs to be cooperation. Gang members need to be honest. If one member is not honest, then it’ll be okay; the majority will overpower the dishonest member. Still, this particular scenario goes back to the initial problem. There are two blockchains. There are two stories. There’s the honest story and the dishonest story. There’s Alice’s story and Bob’s story. If it happens to be that the majority of the gang are dishonest because they want to screw, you know who, poor ol’ Bob, the gang can do it, so the blockchain model can break. It’s much harder to break, but it can break.

We went from trusting Alice which was a disaster, to trusting the TSA, to trusting the gang, which is better but can still fail in the worst-case scenario.

Bitcoin further improves the solution in a very clever way that excitingly works well in practice using a method, known as Proof of Work, where gang members are not registered or identified, allowing Bitcoin to be decentralized and censorship-resistant. The member you trust to add the next block to the chain is the member that’s most financially invested in the gang. Bitcoin has presented new challenges with its drastic innovative changes, but it is still vulnerable to some hypothetical attacks. There has been lots of research on alternatives like variations of proof of virtual work. Only time will tell, but the future looks bright!

Lesson learned: trust is the essence of security, and you cannot escape it.

Origin of blockchain

Satoshi Nakamoto never mentioned “block chain” or “blockchain” when he announced his invention of Bitcoin — he mentioned “block” and “chaining” but never block chain.

The first time block chain was mentioned in a related Bitcoin discussion was between Satoshi and Hal Finney² in the cryptography mailing list, cypherpunk. The term block chain made sense during the time of the discussion because it wasn’t the first time that naming has been used in cryptography. Blockchaining is an encryption method that has existed since 1976 and is still used today, and it works similarly to the blockchaining in blockchain. To further support my definition of blockchain, Hal Finney used block chain in the context of timestamping.

Blockchain as a service

… has existed for +20 years. That’s right. Tell that to your friend and leave them baffled. In 1994, Haber and Stornetta saw the potential in their discovery and started a company called Surety.

However, that doesn’t mean that Surety competes against IBM and other companies invested in blockchain because everyone’s definition of blockchain is different. Like I mentioned in the security section, blockchain includes proof of work when you speak of blockchain in Bitcoinland. Blockchain includes smart contracts when you speak in the Hyperledger world.

Smart Contracts

The goal of the Hyperledger is to build a platform for smart contracts or chaincode, as it’s known in the Hyperledger project. Smart contract was coined by Nick Szabo, the creator of BitGold, a proposal that is awfully similar to Bitcoin, and the arguably leading contender of Satoshi Nakamoto’s true identity.

[Smart contracts] embed contracts in all sorts of property that is valuable and controlled by digital means. Smart contracts reference that property in a dynamic, often proactively enforced form, and provide much better observation and verification where proactive measures must fall short. — Nick Szabo, https://web.archive.org/web/20160312140021/http://szabo.best.vwh.net/idea.html

Whenever there are two or more legal personalities, like a person or corporation, there are usually contracts involved. If a party breaks the contract, the counter-party will take them to court and settle the issue, justly or unjustly — it will be settled with human intervention. This is a reactive solution. Smart contracts are proactive.

The (application’s) code is the contract, and there is no way around it; there shouldn’t be any human intervention at its optimal use case. Of course, there is the possibility of a bug being present in the smart contract code, but it’s argued that a bug is part of the contract; it’s a feature, not a vulnerability. Taking advantage of the feature is not a criminal activity.

A perfect example of this demonstration is the DAO, a smart contract application that allows investors to crowdsource funding in a decentralized environment, so there are no identities and not a single registration system. The DAO received over $152 million in funding, making it the largest crowdsourced project in history.

Later, it was discovered that the numbers in the DAO contract weren’t matching because someone was leaking money from the DAO to their account using a bug no one was aware of. Over $60 million was drained from the DAO using this feature. Call it stealing, but the code is the contract, and the attacker used it as their get-out-of-jail card.

What does this mean for the Hyperledger project? Hyperledger doesn’t focus on decentralized blockchains. In a centralized environment, anyone with the slightest privilege has an identity, so if they try to pull off something clever like the DAO attack, they’ll most likely go to court. This arguably defeats the whole purpose of smart contracts, but the economics of a private blockchain are still unknown. We’ll just have to wait and see how it goes and how IBM handles its end.

My opinions

Haber and Stornetta’s timestamping proposal, as we may know it as blockchain, is not new (relative to internet technology). The innovative part of Bitcoin is the economics and game-theory involved in the security of decentralized blockchains, not blockchain itself. Many companies can benefit from private (centralized) blockchains, but they may be in for disappointment if they end up in a worst-case scenario regarding security. Because of that, IBM should start looking into best practices when deploying blockchains for customers.