
Test-Driven Web Development with Python – The Book - type0
https://www.obeythetestinggoat.com/pages/book.html#toc
======
hpaavola
Robot Framework is a generic test automation tool for acceptance testing and
ATDD and BDD. It's written in Python (py27 and py3 supported, also jython and
IronPython are supported) and should absolutely get at least a mention when
ever testing and python are mentioned.

Check it out [http://robotframework.org/](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](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](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...](https://www.meetup.com/Robot-Framework-
Helsinki/events/251475886/) I'll be there.

~~~
adamhepner
And it greatly simplifies usage of Selenium from what I had witnessed. And it
is relatively easy to use with less-technical people, since you could use
Excel to specify test cases if they wanted to contribute directly. And it is
extremely easy to do data driven testing, or source data directly from test
oracles. And there's extremely active Slack community. The list goes on and on
and on.

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

~~~
Alex3917
> 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
import unittest

class SomeTestThing(unittest.TestCase):

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

What on earth is hard about that?

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

------
michaelmcmillan
Appreciate the book, don't get me wrong – but I've never understood how anyone
can call something a "unit test" when it takes more 2-3 milliseconds to run.

~~~
hjwp3
there's some quite in-depth discussion of this in chapters 23 and 25.
[http://www.obeythetestinggoat.com/book/chapter_purist_unit_t...](http://www.obeythetestinggoat.com/book/chapter_purist_unit_tests.html)
[http://www.obeythetestinggoat.com/book/chapter_hot_lava.html](http://www.obeythetestinggoat.com/book/chapter_hot_lava.html)

------
gautamnarula
I own this book and highly recommend it for anyone interested in TDD,
especially on a web development context.

~~~
sanbor
By just checking the index looks like there is not much about front-end TDD,
which is a real challenge in web developmt (e.g.implementing a calendar UI
widget).

~~~
toyg
IIRC (read it some time ago, likely a previous version) it introduced
Selenium.

~~~
sanbor
It would be interesting about doing TDD with Selenium.

------
Chris2048
Does this book contain any good justifications for TDD that aren't:

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

~~~
teddyh
See for yourself:

[https://www.obeythetestinggoat.com/book/chapter_philosophy_a...](https://www.obeythetestinggoat.com/book/chapter_philosophy_and_refactoring.html)

~~~
Silhouette
Unfortunately it seems the short answer to Chris2048's question is no, the
section linked there doesn't provide any particularly novel arguments for TDD.

~~~
scrollaway
Yep:

> _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)

~~~
hjwp3
Maybe in context it's not so bad?

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

~~~
Chris2048
So, we write tests to deal with complexity, but we are also writing tests for
trivial things because.. something something ninjas.. something something
discipline..

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

------
ZuLuuuuuu
I am trying to choose a book to read to learn testing my _Flask_ web
application. Should I go with "Python Testing with Pytest" by Brian Okken or
the book mentioned in this thread?

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

~~~
matthiaswh
Test Driven Web Development with Python teaches you Django while also teaching
you TDD. As long as you're comfortable with Python it should pose no problem
for you. Many of the principles will be the same with Flask as they are with
Django. It might even be a great learning experience if you take each chapter
and build out the equivalent application in Flask as well as Django.

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.

------
WalterGR
Is there any content about testing using browser automation (e.g. Selenium) or
headless browsers? I don’t see any in the table of contents.

~~~
eksemplar
The first test they do is with selenium, but I can’t tell you anything beyond
that as I just skimmed through the beginning.

------
stevenjohns
I can also highly recommend this book. It's an easy read and would walk you
through a lot of what you need to know if you're new to writing tests or want
to learn to write tests for Django or Flask.

------
wodenokoto
Does there exist any literature on test-driven data science?

~~~
iron0012
Thoughtful Machine Learning by Matthew Kirk is the closest thing I've seen.
It's several years old by now (2014). That said, I don't see many people
trying to use this approach in practice.

------
kimdotcom
Any recommendations for BDD?

~~~
sdoering
"b" as in bug, or "b" as in behavior? Having only recently learned that both
exist I now am never sure what is meant by BDD.

~~~
scaryclam
It's safe to assume behaviour driven development when you see BDD. Bug driven
development is just a term used to point out a project has little or no test
suite and that the devs don't seem to care about testing.

