2 ms·

My point is, when the program is the same as the specification then there's essentially no point writing either tests or proofs. Therefore, I think your point

by tome 9y ago

My point is, when the program is the same as the specification then there's essentially no point writing either tests or proofs. Therefore, I think your point would be better demonstrated using a more complicated example.

kerkeslager 9y ago
This is getting a bit off topic and into the theory of how you write tests, but if you wrote a better test it wouldn't be the same as the specification. def increment(x): return x + 1 def test_increment(): assert increment(0) == 1 assert increment(1) == 2 assert increment(42) == 43 assert increment(-5) == -4 This is admittedly overkill, but the point is you really should only be testing inputs and outputs in a test, not doing calculations. > Therefore, I think your point would be better demonstrated using a more complicated example. The example is a simplification of a bug I came across last year: available_date = datetime.date.today() + datetime.timedelta(days=11) I won't paste the full test here because this is part of a larger function, but rest assured I'm not duplicating the definition of the function in the test. The intern who wrote the code didn't know how to use mocks to mock out `today` so they didn't write a test, resulting in this bug. I remember this case because I use it as an example to teach mocks. I simplified my original example to make it clearer, but I think you'll see that this real-life bug suffers from the same difficulties if you try to verify it with a type system, but is (fairly) easy to test. EDIT: Actually, the relevant bits of the test were fairly simple (from memory so please excuse errors): @unittest.mock('datetime.date.today') def test_available_date_set_to_tomorrow(self, today): today.return_value = datetime.date(1984, 4, 20) [...] ticket_claim = claim_ticket(user, voucher) self.assertEqual( ticket_claim.available_date, datetime.date(1984, 4, 21), )
- tome 9y ago
  Aha, yes, OK, I agree. Good example.

by tome 9y ago

kerkeslager 9y ago

This is getting a bit off topic and into the theory of how you write tests, but if you wrote a better test it wouldn't be the same as the specification. def increment(x): return x + 1 def test_increment(): assert increment(0) == 1 assert increment(1) == 2 assert increment(42) == 43 assert increment(-5) == -4 This is admittedly overkill, but the point is you really should only be testing inputs and outputs in a test, not doing calculations. > Therefore, I think your point would be better demonstrated using a more complicated example. The example is a simplification of a bug I came across last year: available_date = datetime.date.today() + datetime.timedelta(days=11) I won't paste the full test here because this is part of a larger function, but rest assured I'm not duplicating the definition of the function in the test. The intern who wrote the code didn't know how to use mocks to mock out `today` so they didn't write a test, resulting in this bug. I remember this case because I use it as an example to teach mocks. I simplified my original example to make it clearer, but I think you'll see that this real-life bug suffers from the same difficulties if you try to verify it with a type system, but is (fairly) easy to test. EDIT: Actually, the relevant bits of the test were fairly simple (from memory so please excuse errors): @unittest.mock('datetime.date.today') def test_available_date_set_to_tomorrow(self, today): today.return_value = datetime.date(1984, 4, 20) [...] ticket_claim = claim_ticket(user, voucher) self.assertEqual( ticket_claim.available_date, datetime.date(1984, 4, 21), )

tome 9y ago
Aha, yes, OK, I agree. Good example.