New answers tagged

0

tldr; The first "weak" version implies you wrote the entire implementation to pass the one test. You should use each of the brute force tests to drive your implementation, one at a time. Okay the long version. You tagged this with #TDD so I'll answer how I'd do this in a TDD based way. Generally you want to start with the simplest cases first and build ...


2

Say it's broken. Say you're thinking about something else entirely and don't have a lot of patience for this bug. Which test do you wish had been written now? I test as much as I can get away with. At some point you have to stop and get paid. Keeping that in mind, it's not simply behavor. It's the boundaries. Your behavor is 'show me the neighbors'. ...


8

You can do two things: First, use parameterized tests to minimize the duplication of the test code: cases([ [0, [1, 8, 9]], [1, [0, 2, 8, 9, 10]], // more testcases here ]) .it('sample', function(n, expected) { expect(getNeighbors(n)).toEqual(expected); }); Second, partition your testcases into equivalence classes where ...



Top 50 recent answers are included