answer.md

The only evidence of kryptonite I see is the use of strictEqual. This might appear to work because of the term 'strict', but that only refers to type coercion (15 !== '15'). Since our left and right are both complex structures, I suspect the writer was intending to do a deep object comparison.

prompt.md

Inspired by @-julie’s excellent UX shares I’m trying to do something similar by reporting from the dev trenches and sharing lessons learned. 🪖 Nothing shiny and prepared this time…it’s Saturday and I have packing to do.

Can you spot the kryptonite in this jest test? What is weakening this test’s ability to sense change? It’s a very common testing anti-pattern.

You don’t need to see the production code and I’ll let you get away with some basic assumptions about it. For example, it’s pretty mild mannered, no shenanigans like rounding pennies and dumping them in savings accounts or anything like that. It’s real code from a real client’s codebase. In terms of a contract based design I would say it’s pretty average (read ‘lacking’). You don’t know what this function is doing with the arguments you provide it.

it('returns with SUCCESS status if no errors in response', () => {
    const itemSubtotal = '$24.67';
    const inlineBagModelData = {
      itemCount: 21,
      subTotal: '$453.51',
      inlineBagItems: [
        {
          sku: '3914070020002',
          itemSubtotal,
        },
      ],
    };

    const successResponse = {
      errorCode: null,
      itemCount: 21,
      status: 'SUCCESS',
      itemSubtotal,
      inlineBagModelData,
    };
    const addToBagSuccess = {
      inlineBagModelData,
    };

    expect(normalizeLegacyResponse(addToBagSuccess)).toStrictEqual(successResponse);
  });

Have fun! Oh, and for folks that get this right away maybe chill on your response for a bit. Folks that are newer to testing please have a good look and pair up for a few minutes with someone you haven’t had a chance to work with and would really like to.  Explore together! ⛰️ 🌲 🧗‍♀️ 🛶 🌊