Test & Code - Python Testing & Development

Data science, data engineering, data analysis, and machine learning are part of the recent massive growth of Python. But really what is data science? Vicki Boykis helps me understand questions like: No really, what is data science? What does a data pipeline look like? What is it like to do data science, data analysis, data engineering? Can you do analysis on a laptop? How big does data have to be to be considered big? What are the challenges in data science? Does it make sense for software engineers to learn data engineering, data science, pipelines, etc? How could someone start learning data science? Also covered: A type work (analysis) vs B type work (building) data lakes and data swamps predictive models data cleaning development vs experimentation Jupyter Notebooks Kaggle ETL pipelines I learned a lot about the broad field of data science from talking with Vicki.Special Guest: Vicki Boykis.Links:How to Lie with Statistics : Darrell HuffShould you replace Hadoop with your laptop?KaggleProject J

Michael Kennedy of Talk Python and Python Bytes fame joins Brian to talk about being a great guest and what to expect. Even if you have never wanted to be on a podcast, you might learn some great tips. A few of the things we talk about will be helpful for other endeavors, like public speaking, guest blog posts, look for unsolicited job opportunities. Some people have never been on a podcast before, and are possibly freaked out about some of the unknowns of being on a podcast. That's why we did this episode. Michael and I discuss a bunch of the niggly details so that you can be relaxed and know what to expect. Topics include: If you want to be on a podcast How to stand out and be someone a podcast would want to have on a show. How to suggest yourself as a guest and the topic you want to discuss. Picking a topic for a podcast What to do before the show to prepare Helping the host out with some information Some hardware (not much) Some software (all free) Sending info like bio, headshot, links, etc

What happens when 100% test code coverage just isn't enough. In this episode, we talk with Mahmoud Hashemi about glom, a very cool project in itself, but a project that needs more coverage than 100%. This problem affects lots of projects that use higher level programming constructs, like domain specific languages (DSLs), sub languages mini languages, compilers, and db query languages. Also covered: awesome Python applications versioning: 0-ver vs calver vs semver Special Guest: Mahmoud Hashemi.Links:Announcing glom — Restructured Data for PythonDomain-specific language - Wikipediaawesome-python-applications — Free software that works great, and also happens to be open-source Python.Meld — a visual diff and merge tool targeted at developers.ZeroVer: 0-based Versioning SemVer: Semantic Versioning CalVer: Calendar Versioningepisode 27: unit, integration, and system testing - Mahmoud Hashemi

Paul talks about the beginning years of Python. Talking about Python's beginnings is also talking about the Python community beginnings. Yes, it's reminiscing, but it's fun.Special Guest: Paul Everitt.Links:Python 1994 Panel Discussion PyCon 2017"Python 1994", PyBay2017Spam, Spam, Spam, ...

Luc Perkins joins the show to talk about "Seven Databases in Seven Weeks: A guide to modern databases and the NoSQL movement." We discuss a bit about each database: Redis, Neo4J, CouchDB, MongoDB, HBase, Postgres, and DynamoDB.Special Guest: Luc Perkins.Links:Seven Databases in Seven Weeks, Second Edition: A Guide to Modern Databases and the NoSQL MovementPostgreSQLRedisNeo4j Graph DatabaseCouchDBMongoDBHBaseDynamoDB

Brett Cannon discusses the changes afoot in Python packaging as a result of PEP 517, PEP 518, starting with "How did we get here?" and "Where are we going?" Discussed: flit Poetry tox Continuous Integration setup.py, MANIFEST.in, etc. pipenv what's with lock files applications (doesn't go on PyPI) vs libraries (goes on PyPI) workflows dependency resolution deployment dependencies vs development dependencies will lock files be standarized multiple lock files requirements.txt Special Guest: Brett Cannon.Links:FlitPoetryPython Bytes #100 : The big 100 with special guests PEP 517 -- A build-system independent format for source trees | Python.orgPEP 518 -- Specifying Minimum Build System Requirements for Python Projects | Python.org

Andy Knight joins me in discussing the concept of feature testing. A feature tests is "a test verifying a service or library as the customer would use it, but within a single process." That was a quote from an article that appeared on the Twitter engineering blog. The article describes a shift away from class tests towards feature tests, the benefits of the shift, and some reactions to it. Feature tests are similar to something I used to call "functional subcutaneous integration test", but it's a way better name, and I plan to use it more often. The idea fits well with my testing philosophy. Andy Knight is someone still holding onto the testing pyramid. So I thought it would be fun to ask him to discuss feature testing with me. I think it's a balanced discussion. I hope you enjoy it and learn something.Special Guest: Andy Knight.Links:Twitter engineering blog article describing Feature Testing : The testing renaissance

Anthony Shaw joins Brian to discuss flaky tests and flaky test suites. What are flaky tests? Is it the same as fragile tests? Why are they bad? How do we deal with them? What causes flakiness? How can we fix them? How can we avoid them? Proactively rooting out flakiness Test design GUI tests Sharing solutions Special Guest: Anthony Shaw.Links:Dropbox article on flaky testsMicrosoft article on flaky testspytest-rerunfailures: a py.test plugin that re-runs failed tests up to -n times to eliminate flakey failurespytest-randomly: Pytest plugin to randomly order tests and control random.seedpytest-random-order: pytest plugin to randomise the order of tests with some control over the randomnessmath.isclose()numpy.isclose()pytest.approx() — approxAnthony's testing article on RealPythonGhost Inspectorwily: A Python application for tracking, reporting on timing and complexity in tests

tox is a simple yet powerful tool that is used by many Python projects. tox is not just a tool to help you test a Python project against multiple versions of Python. In this interview, Oliver and Brian just scratch the surface of this simple yet powerful automation tool. This is from the tox documentation: tox is a generic virtualenv management and test command line tool you can use for: checking your package installs correctly with different Python versions and interpreters running your tests in each of the environments, configuring your test tool of choice acting as a frontend to Continuous Integration servers, greatly reducing boilerplate and merging CI and shell-based testing. Yet tox is so much more. It can help create development environments, hold all of your admin scripts, ... I hope you enjoy this wonderful discussion of tox with Oliver Bestwalter, one of the core maintainers of tox.Special Guest: Oliver Bestwalter.Links:tox project documentationtox recreate : "Have you turned it off and o

The story of how I came to find a good user interface for running and debugging automated tests is interleaved with a multi-year effort of mine to have a test workflow that’s works smoothly with product development and actually speeds things up. It’s also interleaved with the origins of the blog pythontesting.net, this podcast, and the pytest book I wrote with Pragmatic. It’s not a long story. And it has a happy ending. Well. It’s not over. But I’m happy with where we are now. I’m also hoping that this tale of my dedication to, or obsession with, quality and developer efficiency helps you in your own efforts to make your daily workflow better and to extend that to try to increase the efficiency of those you work with.Links:pythontesting.net

Interview with Andy Knight, the Automation Panda. Selenium & WebDriver Headless Chrome Gherkin BDD Given When Then pytest-bdd PyCharm Writing Good Gherkin Overhead of Gherkin and if it's worth it When to use pytest vs pytest-bdd The art of test automation Special Guest: Andy Knight.Links:Automation Panda | A blog for software development and testingKarate REST API test frameworkBDD | Automation PandaTesting | Automation PandaThe pytest Book

How do you write tests for things that aren’t that easy to write tests for? That question is a possibly terrible summary of a question sent to me by a listener. And to help me start answering that question, I asked a friend of mine to help, Antony Shaw. Of course, different types of applications have different test strategies, so there’s not a universal answer. But I know some of you out there have experience and expertise around how to tackle this problem. Listen to the discussion Anthony and I have about it, and let me know if you have some techniques or tips to add. Special Guest: Anthony Shaw.

David Heinemeier Hansson is the creator of Ruby on Rails, founder & CTO at Basecamp (formerly 37signals). He's a best selling author, public speaker, and even a Le Mans class winning racing driver. All of that, of course, is awesome. But that's not why I asked him on the show. In 2014, during a RailsConf keynote, he started a discussion about damage caused by TDD. This was followed by a few blog posts, and then a series of recorded hangouts with Martin Fowler and Kent Beck. This is what I wanted to talk with David about; this unconventional yet practical and intuitive view of how testing and development work together. It's a great discussion. I think you'll get a lot out of it.Special Guest: David Heinemeier Hansson.Links:Is TDD dead? - Part 1My reaction to "Is TDD Dead?", including links to the other parts of the video seriesRailsConf 2014 - Keynote: Writing Software by David Heinemeier Hansson - YouTubeTDD is dead. Long live testing. (DHH)Test-induced design damage (DHH)Slow database test fallacy (D

After I had wrapped up the interview with Kelsey Hightower for episode 43, I asked him one last question. You see, I admire the his presentation style. So I asked him if he would share with me how he prepared for his presentations. His answer is so thoughtful and makes so much sense, I couldn't keep it to myself. I'm releasing this as a bonus mini-episode so that it's easy to refer back to the next time you or I have a chance to do a technical talk.Special Guest: Kelsey Hightower.

I first heard Kelsey speak during his 2017 PyCon keynote. He's an amazing speaker, and I knew right then I wanted to hear more about what he does and hear more of his story. We discuss testing, of course, but we take it further and discuss: tests for large systems, like kubernetes Testing in real world scenarios with all the configuration and everything Becoming a complete engineer by thinking about the end to end flow from the users perspective Learning from other roles, and the value of roles to allow focus and expertise We even get into Chaos Engineering and testing live systems. Special Guest: Kelsey Hightower.

This interview with Trey Hunner discusses his use of automated tests to help teach programming. Automated testing is a huge part of developing great software. But many new developers don't get exposed to testing for quite a while. But this is changing. New ways to teach programming include automated tests from the beginning. Trey Hunner is one of the PSF directors and a Python and Django team trainer, and he has been using automated tests to help people learn Python.Special Guest: Trey Hunner.Links:Trey HunnerPython Morsels - write better Python codeTrey's Weekly Python ChatTrey's Training business: Truthful Technologyexercism.ioPyBites Code Challenges CheckiO

We talk with Anthony Shaw about some of the testing problems facing both DevOps teams, and Agile teams. We also talk about his recent pull request accepted into pytest.Special Guest: Anthony Shaw.Links:Anthony Shaw on github.ioSupport for the new builtin breakpoint function in Python 3.7 by tonybaloney · Pull Request #3331 · pytest-dev/pytest

Adam is the host of The Gently Mad podcast, and teaches the steps in creating and growing a podcast in his course Irresistible Podcasting. He was one of the people who inspired Brian to get the Test & Code podcast started in the first place. Brian took his course in 2015. Adam is in the process of updating the course, and building a community around it. Warning: This may be an episode to listen to with headphones if you have kids around. There is swearing. I wanted to get Adam's help to convince many of you to either come on this show as a guest, or start your own podcast. We did some of that. But we also cover a lot of issues like self doubt and the importance of community.Special Guest: Adam Clark.Links:Irresistible Podcasting – A Step by Step Guide to Launching and Growing a Podcast that Can’t Be IgnoredThe Gently Mad – Life, business & entrepreneurship without the bullshit.avclark.comJustin Jacksons episodes on minimal podcasting | Build and LaunchDan Benjamin's Podcast Method podcastPython Byt

Complete and exhaustive testing is not possible. Nor would it be fun, or maintainable, or a good use of your time. However, some functionality is important enough to make sure the test behavior coverage is thorough enough to have high confidence in it's quality. In this episode, we discuss 3 techniques that can be combined to quickly generate test cases. We then talk about how to implement them efficiently in pytest. The techniques covered are: equivalence partitioning boundary value analysis decision tables We discuss how to use these to generate test cases for a new list filter functionality in the cards application. The resulting tests: 1 UI test to make sure the options are able to be passed in correctly. 1 small parametrized test function with 16 single line parameter sets representing the different test cases. Links:github cards project (version 0.1.11)Equivalence partitioning - WikipediaBoundary-value analysis - WikipediaDecision table - WikipediaSlack Channel for Test and CodeDJ YANiC - The

RCRCRC was developed by Karen Nicole Johnson. In this episode we discuss the mnemonic/heuristic and use it to prioritize tests for the cards application. Recent: new features, new areas of code Core: essential functions must continue to work, your products USPs (Unique Selling Propositions) Risk: some areas of an application pose more risk, perhaps areas important to customers but not used regularly by the development team. Configuration sensitive: code that’s dependent on environment settings or operating system specifics Repaired: tests to reproduce bugs, tests for functionality that has been recently repaired. Chronic: functionality that frequently breaks Links:A heuristic for regression testing, by Karen Nicole Johnson@karennjohnsoncards on githubcards on Travis CIcards on AppVeyor