6 ms·
Test-Driven Web Development with Python – The Book
- gautamnarula 8y agoI own this book and highly recommend it for anyone interested in TDD, especially on a web development context.
- cjcampbell 8y agoI think its value goes beyond the focus on TDD. It’s a nice introduction for a beginner who wants to learn about the discipline of managing code and development processes. If I recall correctly, the author assumes very little knowledge and walks the reader step-by-step through proper use of git, etc.
- sanbor 8y agoBy 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).
- kimdotcom 8y agoAny recommendations for BDD?
- sdoering 8y ago"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 8y agoIt'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.
- scaryclam 8y agoIn Python? I'd recommend behave. You can mix it with selenium if you're looking for some web coverage as well.
- hjwp3 8y agothere's an appendix with a v brief discussion: http://www.obeythetestinggoat.com/book/appendix_bdd.html http://www.obeythetestinggoat.com/book/appendix_bdd.html
- stevenjohns 8y agoI 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.
- deleted 8y ago[deleted]
- WalterGR 8y agoIs 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 8y agoThe first test they do is with selenium, but I can’t tell you anything beyond that as I just skimmed through the beginning.
- matthiaswh 8y agoYes, from what I recall, any time the author talks about functional tests he is using Selenium.
- yegle 8y agoI 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 agoCode 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 agoCode coverage is good but not sufficient (you can execute code but not verify the result etc.)
- Matt3o12_ 8y agoI 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.
- hpaavola 8y agoRobot 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/251475886/ https://www.meetup.com/Robot-Framework-Helsinki/events/25147... I'll be there.
- adamhepner 8y agoAnd 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.
- ZuLuuuuuu 8y agoI 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 8y agoTest 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.
- senthil_rajasek 8y agoI had a similar question. Django is not python.
- michaelmcmillan 8y agoAppreciate 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 8y agothere's some quite in-depth discussion of this in chapters 23 and 25. http://www.obeythetestinggoat.com/book/chapter_purist_unit_tests.html http://www.obeythetestinggoat.com/book/chapter_purist_unit_t... http://www.obeythetestinggoat.com/book/chapter_hot_lava.html http://www.obeythetestinggoat.com/book/chapter_hot_lava.html
- Chris2048 8y agoDoes 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 8y agoSee for yourself: https://www.obeythetestinggoat.com/book/chapter_philosophy_and_refactoring.html https://www.obeythetestinggoat.com/book/chapter_philosophy_a...
- projektfu 8y agohttps://www.obeythetestinggoat.com/book/chapter_philosophy_and_refactoring.html#_programming_is_like_pulling_a_bucket_of_water_up_from_a_well https://www.obeythetestinggoat.com/book/chapter_philosophy_a... That might be a better link to the same material.
- Silhouette 8y agoUnfortunately 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 8y agoYep: > 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 8y agoMaybe 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.
- lerie82 8y agothis feels like a book review/sales ploy, how is this news?
- wodenokoto 8y agoDoes there exist any literature on test-driven data science?
- iron0012 8y agoThoughtful 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.