Tag: toBe vs toEqual

Hey there, if you enjoy this little tale about JavaScript testing, feel free to give it a like or share it with someone who loves coding stories!

---

I’m in a park, the sun shining bright, and there’s a group of us playing with a frisbee. Now, catching a frisbee mid-air is quite the art—it’s all about precision and timing. In the world of JavaScript testing with Jest, matchers are like my skills for catching that frisbee. They help me decide if the catch is perfect or if I need to adjust my technique.

As we’re playing, my friend throws the frisbee towards me. I leap into the air, reaching out with my hand. This moment, right here, is where toBe comes into play. It’s like that instant when I want to catch the frisbee exactly as it is, without any alterations. If I’m expecting a red frisbee, I want to catch only a red frisbee—no other color will do. toBe checks for that exact match, just like my hand is calibrated to catch that specific frisbee.

Now, imagine another scenario. This time, my friend throws a frisbee that’s the same shape and size but painted with different patterns. Even though it looks different, the essence of the frisbee remains unchanged. That’s where toEqual comes into play. It’s like I’m focusing on the core attributes of the frisbee—the shape and size—rather than the paint job. toEqual allows me to recognize that even if the frisbee has changed slightly in appearance, it’s fundamentally the same.

So, there I am, leaping and diving, using my toBe and toEqual skills to make sure I catch the frisbee just right. Matchers in Jest are my trusty guides, helping me determine whether each catch is a success or if I need a little more practice. And as the game goes on, I become more adept at distinguishing between the exact matches and the ones that are equal in essence. Just like in JavaScript testing, it’s all about knowing what to expect and being ready for it.

---

First, I imagine the toBe matcher, just like catching the exact red frisbee mid-air. I write a simple test to ensure two variables are exactly the same:

test('checks if two numbers are exactly the same', () => {
  const speedOfFrisbee = 30; // in mph
  expect(speedOfFrisbee).toBe(30);
});

In this test, toBe is like catching that specific red frisbee. The speedOfFrisbee variable must be exactly 30, just like my hand reaching for that exact match.

Next, I think about the toEqual matcher, where the frisbee’s core attributes matter more than its color. I write another test, this time using objects to illustrate the concept:

test('checks if two objects are structurally equivalent', () => {
  const frisbee1 = { diameter: 10, weight: 1.2 };
  const frisbee2 = { diameter: 10, weight: 1.2 };

  expect(frisbee1).toEqual(frisbee2);
});

Here, toEqual is my deep understanding of the frisbee’s essence. Even though frisbee1 and frisbee2 might have different colors or labels in a real-world scenario, their core properties—the diameter and weight—are what matter, just like the shape and size of a frisbee in my hands.

As I wrap up my coding session, I jot down some key takeaways:

1. Precision with toBe: Use toBe for primitive values like numbers and strings, where exactness is crucial. It’s like catching the frisbee that matches perfectly.
2. Structural Comparison with toEqual: Use toEqual for complex structures like objects and arrays, focusing on their core attributes rather than surface differences. It’s about recognizing the essence of the frisbee.
3. Choosing the Right Matcher: Just like selecting the right technique to catch a frisbee, choosing between toBe and toEqual depends on what I’m testing—exact matches or structural equivalence.