5 ms·

I own this book and really enjoyed it. One day, as usual, I wrote some code, then added additional test cases to cover the new code path. Each new test case pa

by yegle 8y ago

I own this book and really enjoyed it. One day, as usual, I wrote some code, then added additional test cases to cover the new code path. Each new test case passed without further fix, I was feeling really good that day. Until when I realized all my new testXXX method was defined with one extra layer of indentation and all became local functions of the last existing test case. Then I recall the first step of TDD from the book: always write the test first and confirm it does fail.

bobbyi_settv 8y ago
Code coverage tools are useful for that scenario too. If you don't see 100% of your test code being executed when your test suite is run, something has gone wrong.
- Boulth 8y ago
  Code coverage is good but not sufficient (you can execute code but not verify the result etc.)
  - Matt3o12_ 8y ago
    I think he was referring to check that the tests are actually run. This is especially useful for language that don’t complain if something looks like a test but isn’t being executed for some reason. I have written tests where I made some mistake (named the file, class, function incorrectly or forgot a parameter) and the test was never run. I would have discovered it with test coverage but I learned it the hard way (when a bug/edge case occurred for which I have written this test specifically).
Alex3917 8y ago
> always write the test first and confirm it does fail. Unless you're a QA engineer and all you do is write tests, it's pretty difficult to actually write a test in Python just starting from a blank page. The syntax is extremely arbitrary and even the concepts are pretty confusing, so unless you're just copying another test from your codebase that already works and then modifying it, it's pretty unlikely that your test will even compile let alone actually do anything. It's not super hard to write tests if you already have working code and then confirm that they fail afterwards, but I have a lot of trouble imagining actually doing TDD in Python. That said it is a great book and I learned a lot from it.
- scaryclam 8y ago
  import unittest class SomeTestThing(unittest.TestCase): def some_test(self): self.assertTrue(False) What on earth is hard about that?
  - mapleoin 8y ago
    You're overcomplicating it, use pytest :P def test_some(): assert False is True (no need for imports, classes and special assertion methods if you're just writing a simple test)
    - yebyen 8y ago
      You're both being silly, but honestly not too silly... Many people when attempting to do TDD, will work too hard at writing a "complete test" and fail at it, because they really don't know exactly what the feature is going to look like when it's done. That's not the point of TDD at all. Your example of asserting False is True is quite obviously a hyperbole, as it only gets you one thing: you can confirm the test is actually being run. But that's a start, right? Then you can go slightly above that threshold and let the test help you confirm that (for example) the div tag with the correct ID is not yet on the page. Doesn't matter what ID you choose perhaps, because you'll be the person putting it on the page in the next step, to make the test pass. And then you can assert the content of the div matches your expectation... finally what's left to test? That wasn't so hard, was it? This is only one example, not every (unit) test is supposed to result in text being rendered inside of a div, but the point is that you can do Test-First design even before you know exactly what units will be in the actual solution, by starting with the integration test. Or go a single layer up the stack and, for example, test your views indirectly by checking that the controller can render them. IMHO you absolutely do not need to make up a complete unit test suite before you've coded any of the units. That is not the point of TDD. The point is just to test (and especially, to not forget to test, by exercising systems for testing regularly and using the test-first approach as often as possible.) My preferred development environment is not Python, but it's not for some reason like because I don't like Python. I just learned on Ruby and happened to get a job that wants me to code Ruby. So I use RSpec and Cucumber, where the principles are all the same as I understand it, and so are all of the developer hand-wringings and excuses. It is better to assert False is True than it is to have never seen the test failing at all.
reisender 8y ago
Another fun issues, if you copy and paste the tests and forget to change the name/signature of the function. Looks like everything is working until you realize that not all tests are actually run. Always, test and fail first :)
- js2 8y ago
  pylint should catch that mistake.

by yegle 8y ago

bobbyi_settv 8y ago

Code coverage tools are useful for that scenario too. If you don't see 100% of your test code being executed when your test suite is run, something has gone wrong.

Boulth 8y ago
Code coverage is good but not sufficient (you can execute code but not verify the result etc.)
- Matt3o12_ 8y ago
  I think he was referring to check that the tests are actually run. This is especially useful for language that don’t complain if something looks like a test but isn’t being executed for some reason. I have written tests where I made some mistake (named the file, class, function incorrectly or forgot a parameter) and the test was never run. I would have discovered it with test coverage but I learned it the hard way (when a bug/edge case occurred for which I have written this test specifically).

Alex3917 8y ago

> always write the test first and confirm it does fail. Unless you're a QA engineer and all you do is write tests, it's pretty difficult to actually write a test in Python just starting from a blank page. The syntax is extremely arbitrary and even the concepts are pretty confusing, so unless you're just copying another test from your codebase that already works and then modifying it, it's pretty unlikely that your test will even compile let alone actually do anything. It's not super hard to write tests if you already have working code and then confirm that they fail afterwards, but I have a lot of trouble imagining actually doing TDD in Python. That said it is a great book and I learned a lot from it.

scaryclam 8y ago
import unittest class SomeTestThing(unittest.TestCase): def some_test(self): self.assertTrue(False) What on earth is hard about that?
- mapleoin 8y ago
  You're overcomplicating it, use pytest :P def test_some(): assert False is True (no need for imports, classes and special assertion methods if you're just writing a simple test)
  - yebyen 8y ago
    You're both being silly, but honestly not too silly... Many people when attempting to do TDD, will work too hard at writing a "complete test" and fail at it, because they really don't know exactly what the feature is going to look like when it's done. That's not the point of TDD at all. Your example of asserting False is True is quite obviously a hyperbole, as it only gets you one thing: you can confirm the test is actually being run. But that's a start, right? Then you can go slightly above that threshold and let the test help you confirm that (for example) the div tag with the correct ID is not yet on the page. Doesn't matter what ID you choose perhaps, because you'll be the person putting it on the page in the next step, to make the test pass. And then you can assert the content of the div matches your expectation... finally what's left to test? That wasn't so hard, was it? This is only one example, not every (unit) test is supposed to result in text being rendered inside of a div, but the point is that you can do Test-First design even before you know exactly what units will be in the actual solution, by starting with the integration test. Or go a single layer up the stack and, for example, test your views indirectly by checking that the controller can render them. IMHO you absolutely do not need to make up a complete unit test suite before you've coded any of the units. That is not the point of TDD. The point is just to test (and especially, to not forget to test, by exercising systems for testing regularly and using the test-first approach as often as possible.) My preferred development environment is not Python, but it's not for some reason like because I don't like Python. I just learned on Ruby and happened to get a job that wants me to code Ruby. So I use RSpec and Cucumber, where the principles are all the same as I understand it, and so are all of the developer hand-wringings and excuses. It is better to assert False is True than it is to have never seen the test failing at all.

reisender 8y ago

Another fun issues, if you copy and paste the tests and forget to change the name/signature of the function. Looks like everything is working until you realize that not all tests are actually run. Always, test and fail first :)

js2 8y ago
pylint should catch that mistake.