4 ms·
Something like: assertEquals(0, add(0,0)) assertEquals(1, add(0,1)) assertEquals(2, add(1,1)) assertEquals(8, add(3,5)) assertEquals(-3, ad
by zeroimpl 5y ago
Something like:
assertEquals(0, add(0,0))
assertEquals(1, add(0,1))
assertEquals(2, add(1,1))
assertEquals(8, add(3,5))
assertEquals(-3, add(2,-5))
PS: This kind of proves why a test is a lot less useful than the algorithm. Try figuring out how to implement "add" from the above test.
- anonytrary 5y agoPersonally I see this a lot and I'm not a fan: it('should work', () => { inputOutputPairs.forEach(([input, output]) => { expect(testedFunction(input)).equals(output); }) }) Tests are way more useful when they are written with the intent of acting as documentation. If I had to give this test a grade (from F- to A+), it would get a D+. It catches regressions, yet does an absolutely horrid job of explaining the intent behind testedFunction.
- ramses0 5y agocases = [ { in: 1, arg: 2, expected: 3, message: "base case" }, { in: 2, arg: -2, expected: 0, message: "negative numbers" }, ... ] for ( c in cases ) { actual = obj.do( c.in, c.arg ) assert( actual == c.expected, c.message ) } see: http://fit.c2.com/ http://fit.c2.com/ ... table-based testing, "cases" and "drivers"