Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> 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.



Doing TDD in Python every day. Done that with other languages in the past and can't see any difference, so I'm curious to understand why you have this feeling.


Built multiple complex systems using TDD and the unittest package in Python. No monolithic frameworks, almost zero test infrastructure and ~ 1000 unit tests/sec. Do not share your perspective.


import unittest

class SomeTestThing(unittest.TestCase):

    def some_test(self):
        self.assertTrue(False)

What on earth is hard about that?


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)


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: