Check it out http://robotframework.org/ There are bunch of ready made libraries for it to test many kind of applications (web [also Electron apps], mobile, databases, rest APIs, MQTT, ...) http://robotframework.org/#libraries and writing new libraries is really simple.

Here's a 16 minute video made by me on how to use User Stories or similar material as tests with Robot Framework https://www.youtube.com/watch?v=kNUJ1z8NUQo It also acts as a short introduction to RF.

If you happen to live in Helsinki region, there's a Robot Framework meetup later today in Espoo https://www.meetup.com/Robot-Framework-Helsinki/events/25147... I'll be there.

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.

Always, test and fail first :)

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.

class SomeTestThing(unittest.TestCase):

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

  def test_some():
      assert False is True

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.

a) justifications for testing/ writing unit test, not TDD specifically

b) hand-wavey "it's not hard, so why resist"

c) pitching it as a way of practising writing tests, as opposed to a real development methodology in itself

https://www.obeythetestinggoat.com/book/chapter_philosophy_a...

That might be a better link to the same material.

> Firstly, if they’re really trivial tests, then they won’t take you that long to write them. So stop moaning and just write them already.

This... is not a great impression of the book I'm getting. (Edit: I say that as someone who has heavily practiced TDD in situations where it's appropriate)

> On the Merits of Trivial Tests for Trivial Functions

> In the short term it may feel a bit silly to write tests for simple functions and constants.

> It’s perfectly possible to imagine still doing “mostly” TDD, but following more relaxed rules where you don’t unit test absolutely everything. But in this book my aim is to demonstrate full, rigorous TDD. Like a kata in a martial art, the idea is to learn the motions in a controlled context, when there is no adversity, so that the techniques are part of your muscle memory. It seems trivial now, because we’ve started with a very simple example. The problem comes when your application gets complex—​that’s when you really need your tests. And the danger is that complexity tends to sneak up on you, gradually. You may not notice it happening, but quite soon you’re a boiled frog.

> There are two other things to say in favour of tiny, simple tests for simple functions.

> Firstly, if they’re really trivial tests, then they won’t take you that long to write them. So stop moaning and just write them already.

> Secondly, it’s always good to have a placeholder. Having a test there for a simple function means it’s that much less of a psychological barrier to overcome when the simple function gets a tiny bit more complex—​perhaps it grows an if. Then a few weeks later it grows a for loop. Before you know it, it’s a recursive metaclass-based polymorphic tree parser factory. But because it’s had tests from the very beginning, adding a new test each time has felt quite natural, and it’s well tested. The alternative involves trying to decide when a function becomes “complicated enough”, which is highly subjective, but worse, because there’s no placeholder, it seems like that much more effort, and you’re tempted each time to put it off a little longer, and pretty soon—​frog soup!

> Instead of trying to figure out some hand-wavy subjective rules for when you should write tests, and when you can get away with not bothering, I suggest following the discipline for now—​as with any discipline, you have to take the time to learn the rules before you can break them.

So what's this got to do with selling TDD? You can write "placeholder" tests afterwards just as easily..

"Test-Driven Web Development with Python" book says it uses Django and I don't know Django. So I am hesitating to read this book even though I want to learn TDD for my web app.

PS: I don't have much TDD experience.

It's a very good book and easy to consume, and also available for free online. However, I have not read Python Testing with PyTest so I cannot compare them or answer which is better for you.