Repository navigation
Manchester | 26-ITP-Sep | Mathew Shaibu | Sprint 2 | Module data group sprint 2 - #1499
MattCarolus10 wants to merge 60 commits into
Conversation
…ecks and comments
…comments and whitespace
| // implementation here | ||
| function createLookup(countryCurrencyPairs) { | ||
| const lookup = {}; | ||
| for (const [country, currency] of countryCurrencyPairs) { |
There was a problem hiding this comment.
Neat use of array destructuring!
| test("creates a country currency code lookup for multiple codes", () => { | ||
| expect( | ||
| createLookup([ | ||
| ["US", "USD"], | ||
| ["CA", "CAD"], | ||
| ]) | ||
| ).toEqual({ US: "USD", CA: "CAD" }); | ||
| }); |
There was a problem hiding this comment.
One test is rarely enough to comprehensively cover all behaviours of a function. Can you think of what some other good test cases might be?
| const k = decodeURIComponent(key.split("+").join(" ")); | ||
| const v = decodeURIComponent(value.split("+").join(" ")); |
There was a problem hiding this comment.
Single-letter variable names are something we generally want to avoid - what would be more descriptive choices for these variable? What do k and v actually represent?
| test("tally on an empty array returns an empty object", () => { | ||
| expect(tally([])).toEqual({}); | ||
| }); | ||
|
|
||
| // Given a function called tally | ||
| // When passed an array of items | ||
| // Then it should return an object containing the count for each unique item | ||
| test("tally counts duplicate items", () => { | ||
| expect(tally(["a", "a", "a"])).toEqual({ a: 3 }); | ||
| expect(tally(["a", "a", "b", "c"])).toEqual({ a: 2, b: 1, c: 1 }); | ||
| }); |
There was a problem hiding this comment.
When building up tests with TDD, it isn't always as direct as "1 test per acceptance criteria". We want to think about the different behaviours of this function and increasing complexity of the inputs in small increments.
Your second test here contains two assertions which have notably different inputs. One of them has the same letter 3 times and that's it. The other one has multiple letters. You're checking two different things here:
- Can the function count multiple occurrences of the same letter?
- Can the function count occurrences of different letters?
Those are distinct behaviours, so they should be separate tests.
| expect(() => tally("banana")).toThrow("tally requires an array"); | ||
| expect(() => tally(42)).toThrow("tally requires an array"); | ||
| expect(() => tally()).toThrow("tally requires an array"); | ||
| }); |
There was a problem hiding this comment.
A great example of using multiple assertions that are all checking the same behaviour - a non-array input.
| const invert = require("./invert.js"); | ||
|
|
||
| test("swaps key with values", () => { | ||
| expect(invert({ x: 10, y: 20 })).toEqual({ 10: "x", 20: "y" }); | ||
| }); | ||
|
|
||
| test("handles single entry", () => { | ||
| expect(invert({ a: 1 })).toEqual({ 1: "a" }); | ||
| }); | ||
|
|
||
| test("handles an empty object", () => { | ||
| expect(invert({})).toEqual({}); | ||
| }); |
There was a problem hiding this comment.
Extra credit for adding a test suite when we didn't ask! 🌟
Just a quick note on TDD test building. As I mentioned in an earlier comment, we want to start with simpler inputs and get more complex as we go. Here, your tests are all good but not in the right order. If you were building the function step-by-step with TDD, you'd have them in the exact reverse order.
You don't need to change this but I wanted to highlight it to remind you of good TDD practices.
|
Hi @MattCarolus10 ! Sorry about the labels jumping around, I was using your PR to demonstrate a code review. Good work overall, I've left some comments on a few things that could be improved. Take a look and let me know if you have any questions 🙂 |
Self checklist
Task code
CYF-1083
Changelist
I completed debugging task, implemented test and created function and interpreted codes