Also, I should have tested it better. :)
In the audio I got the numbers wrong. Doh!
This is episode 238, not 237. Oh well.
I'll still be around, of course, at:
- pythontest.com - where I write about developing software with tests
- pythonbytes.fm - Python news and headlines, delivered directly to your earbuds
Thanks for all the fun over the last 10 years.
I wish you the best.
Also, I should have tested it better. :)
In the audio I got the numbers wrong. Doh!
This is episode 238, not 237. Oh well.
I'll still be around, of course, at:
- pythontest.com - where I write about developing software with tests
- pythonbytes.fm - Python news and headlines, delivered directly to your earbuds
Thanks for all the fun over the last 10 years.
I wish you the best.
Also, I should have tested it better. :)
In the audio I got the numbers wrong. Doh!
This is episode 238, not 237. Oh well.
I'll still be around, of course, at:
- pythontest.com - where I write about developing software with tests
- pythonbytes.fm - Python news and headlines, delivered directly to your earbuds
Thanks for all the fun over the last 10 years.
I wish you the best.
Links:
Links:
Links:
Key topics include
- "cherry picking" for selective commits
- "git stash" for managing in-progress work
- "git diff", and specifically its `--name-only` flag, which provides a streamlined method for developers to identify which files have changed, which can be used to determine which tests need to be run
- "git bisect" for efficiently pinpointing bugs.
This conversation offers valuable strategies for developers at any skill level to enhance their Git proficiency and optimize their coding workflows.
Links:
- Boost Your Git DX - Adam's book
Key topics include
- "cherry picking" for selective commits
- "git stash" for managing in-progress work
- "git diff", and specifically its `--name-only` flag, which provides a streamlined method for developers to identify which files have changed, which can be used to determine which tests need to be run
- "git bisect" for efficiently pinpointing bugs.
This conversation offers valuable strategies for developers at any skill level to enhance their Git proficiency and optimize their coding workflows.
Links:
- Boost Your Git DX - Adam's book
Key topics include
- "cherry picking" for selective commits
- "git stash" for managing in-progress work
- "git diff", and specifically its `--name-only` flag, which provides a streamlined method for developers to identify which files have changed, which can be used to determine which tests need to be run
- "git bisect" for efficiently pinpointing bugs.
This conversation offers valuable strategies for developers at any skill level to enhance their Git proficiency and optimize their coding workflows.
Links:
- Boost Your Git DX - Adam's book
Links:
- pytest-django - a plugin for pytest that provides a set of useful tools for testing Django applications and projects.
Links:
- pytest-django - a plugin for pytest that provides a set of useful tools for testing Django applications and projects.
Links:
- pytest-django - a plugin for pytest that provides a set of useful tools for testing Django applications and projects.
That is such a humble description for such a massively useful plugin.
If you're already using pytest-html, you have pytest-metadata already installed, as pytest-metadata is one of the dependencies for pytest-html.
However, pytest-metadata is very useful even on its own.
Links:
- pytest-metadata - The plugin we're talking about in this episode
- pytest-base-url - Adds the base URL to the metadata.
- pytest-html - Displays the metadata at the start of each report.
- pytest-reporter-html1 - Presents metadata as part of the report.
- pytest-selenium - Adds the driver, capabilities, and remote server to the metadata.
If you've got other plugins that work well with pytest-metadata, please let me know.
That is such a humble description for such a massively useful plugin.
If you're already using pytest-html, you have pytest-metadata already installed, as pytest-metadata is one of the dependencies for pytest-html.
However, pytest-metadata is very useful even on its own.
Links:
- pytest-metadata - The plugin we're talking about in this episode
- pytest-base-url - Adds the base URL to the metadata.
- pytest-html - Displays the metadata at the start of each report.
- pytest-reporter-html1 - Presents metadata as part of the report.
- pytest-selenium - Adds the driver, capabilities, and remote server to the metadata.
If you've got other plugins that work well with pytest-metadata, please let me know.
That is such a humble description for such a massively useful plugin.
If you're already using pytest-html, you have pytest-metadata already installed, as pytest-metadata is one of the dependencies for pytest-html.
However, pytest-metadata is very useful even on its own.
Links:
- pytest-metadata - The plugin we're talking about in this episode
- pytest-base-url - Adds the base URL to the metadata.
- pytest-html - Displays the metadata at the start of each report.
- pytest-reporter-html1 - Presents metadata as part of the report.
- pytest-selenium - Adds the driver, capabilities, and remote server to the metadata.
If you've got other plugins that work well with pytest-metadata, please let me know.
Normally, a test function will fail and stop running with the first failed assert. That's totally fine for tons of kinds of software tests. However, there are times where you'd like to check more than one thing, and you'd really like to know the results of each check, even if one of them fails.
pytest-check allows multiple failed "checks" per test function, so you can see the whole picture of what's going wrong.
Links:
Normally, a test function will fail and stop running with the first failed assert. That's totally fine for tons of kinds of software tests. However, there are times where you'd like to check more than one thing, and you'd really like to know the results of each check, even if one of them fails.
pytest-check allows multiple failed "checks" per test function, so you can see the whole picture of what's going wrong.
Links:
Normally, a test function will fail and stop running with the first failed assert. That's totally fine for tons of kinds of software tests. However, there are times where you'd like to check more than one thing, and you'd really like to know the results of each check, even if one of them fails.
pytest-check allows multiple failed "checks" per test function, so you can see the whole picture of what's going wrong.
Links:
Tests are one of those things that some people don't like to write.
Can AI play a role in creating automated software tests?
Well, yes. But it's a nuanced yes.
Anthony Shaw comes on the show to discuss the topic and try to get AI to write some test for my very own cards project.
We discuss:
- The promise of AI writing your tests for you
- Downsides to not writing tests yourself
- Bad ways to generate tests
- Good ways to ask AI for help in writing tests
- Tricks to get better results while using copilot and other AI tools
Links:
- The cards project
- A video version of this discussion: Should AI write tests?
Tests are one of those things that some people don't like to write.
Can AI play a role in creating automated software tests?
Well, yes. But it's a nuanced yes.
Anthony Shaw comes on the show to discuss the topic and try to get AI to write some test for my very own cards project.
We discuss:
- The promise of AI writing your tests for you
- Downsides to not writing tests yourself
- Bad ways to generate tests
- Good ways to ask AI for help in writing tests
- Tricks to get better results while using copilot and other AI tools
Links:
- The cards project
- A video version of this discussion: Should AI write tests?
Tests are one of those things that some people don't like to write.
Can AI play a role in creating automated software tests?
Well, yes. But it's a nuanced yes.
Anthony Shaw comes on the show to discuss the topic and try to get AI to write some test for my very own cards project.
We discuss:
- The promise of AI writing your tests for you
- Downsides to not writing tests yourself
- Bad ways to generate tests
- Good ways to ask AI for help in writing tests
- Tricks to get better results while using copilot and other AI tools
Links:
- The cards project
- A video version of this discussion: Should AI write tests?
- is a pytest plugin that makes it easy to repeat a single test, or multiple tests, a specific number of times.
- works fine on Python 3.14
- is tested on Python 3.9-3.14
- probably works fine still on 3.7 & 3.8
This episode also discusses the attempted April Fools episode.
Links:
- pytest-repeat
- The April Fools episode: Python 3.14 won't repeat with pytest-repeat
- is a pytest plugin that makes it easy to repeat a single test, or multiple tests, a specific number of times.
- works fine on Python 3.14
- is tested on Python 3.9-3.14
- probably works fine still on 3.7 & 3.8
This episode also discusses the attempted April Fools episode.
Links:
- pytest-repeat
- The April Fools episode: Python 3.14 won't repeat with pytest-repeat
- is a pytest plugin that makes it easy to repeat a single test, or multiple tests, a specific number of times.
- works fine on Python 3.14
- is tested on Python 3.9-3.14
- probably works fine still on 3.7 & 3.8
This episode also discusses the attempted April Fools episode.
Links:
- pytest-repeat
- The April Fools episode: Python 3.14 won't repeat with pytest-repeat
Note: This was an April Fools attempt, so the statement ...
"Unfortunately, it doesn't seem to work with Python 3.14, even though there is no rational reason why it shouldn't work."
... is NOT true.
Listen to the NEXT episode to get an explanation
Links:
- pytest-repeat
- Next episode: pytest-repeat - works fine on Python 3.14
Note: This was an April Fools attempt, so the statement ...
"Unfortunately, it doesn't seem to work with Python 3.14, even though there is no rational reason why it shouldn't work."
... is NOT true.
Listen to the NEXT episode to get an explanation
Links:
- pytest-repeat
- Next episode: pytest-repeat - works fine on Python 3.14
Note: This was an April Fools attempt, so the statement ...
"Unfortunately, it doesn't seem to work with Python 3.14, even though there is no rational reason why it shouldn't work."
... is NOT true.
Listen to the NEXT episode to get an explanation
Links:
- pytest-repeat
- Next episode: pytest-repeat - works fine on Python 3.14
pytest-html is a plugin for pytest that generates a HTML report for test results.
This episode digs into some of the super coolness of pytest-html.
pytest-html is a plugin for pytest that generates a HTML report for test results.
This episode digs into some of the super coolness of pytest-html.
pytest-html is a plugin for pytest that generates a HTML report for test results.
This episode digs into some of the super coolness of pytest-html.
Two fun plugins discussed.
Links:
Two fun plugins discussed.
Links:
Two fun plugins discussed.
Links:
We lost Michael in January, and I'd like to revisit this interview as a tribute.
Michael Foord was a pivotal figure in the Python community and the creator of the mock library that's now unittest.mock.
But he did so much more as well.
His contributions continue to resonate within the developer community.
This interview is just a small peek at his influence.
In this episode
- Introduction to Michael Foord
- The Mock Library Origins
- Mocking and Testing Philosophy
- Career Path and Consulting
- Understanding Mocking
- The Power of Patch
- Testing Strategies and Design
- Mocking External Dependencies
- Teaching Testing and Mocking
python.org has put up an "In memoriam" page for Michael Foord, and many people have shared stories and memories.
Links:
We lost Michael in January, and I'd like to revisit this interview as a tribute.
Michael Foord was a pivotal figure in the Python community and the creator of the mock library that's now unittest.mock.
But he did so much more as well.
His contributions continue to resonate within the developer community.
This interview is just a small peek at his influence.
In this episode
- Introduction to Michael Foord
- The Mock Library Origins
- Mocking and Testing Philosophy
- Career Path and Consulting
- Understanding Mocking
- The Power of Patch
- Testing Strategies and Design
- Mocking External Dependencies
- Teaching Testing and Mocking
python.org has put up an "In memoriam" page for Michael Foord, and many people have shared stories and memories.
Links:
We lost Michael in January, and I'd like to revisit this interview as a tribute.
Michael Foord was a pivotal figure in the Python community and the creator of the mock library that's now unittest.mock.
But he did so much more as well.
His contributions continue to resonate within the developer community.
This interview is just a small peek at his influence.
In this episode
- Introduction to Michael Foord
- The Mock Library Origins
- Mocking and Testing Philosophy
- Career Path and Consulting
- Understanding Mocking
- The Power of Patch
- Testing Strategies and Design
- Mocking External Dependencies
- Teaching Testing and Mocking
python.org has put up an "In memoriam" page for Michael Foord, and many people have shared stories and memories.
Links:
pytest-mock is a wrapper around unittest.mock.
In this episode:
- Why the pytest-mock plugin is awesome
- What is mocking, patching, and monkey patching
- What, if any, is the difference between mock, fake, spy, stub.
- Why we might need these in testing
- Some history of mock in Python and how mock became unittest.mock
- From unittest.mock
- patch.object
- patch.object with autospec
- using these as context managers
- pytest-mock:
- The mocker fixture
- Cleanup in teardown
- Using mocker.patch, mocker.spy, and mocker.stub
- Why it's awesome and why you might want to use it over straight unittest.mock
Links:
- top pytest plugins list
- pytest-mock documentation
- unittest.mock
- Podcast episode discussing unittest.mock with Michael Foord
- monkeypatch
pytest-mock is a wrapper around unittest.mock.
In this episode:
- Why the pytest-mock plugin is awesome
- What is mocking, patching, and monkey patching
- What, if any, is the difference between mock, fake, spy, stub.
- Why we might need these in testing
- Some history of mock in Python and how mock became unittest.mock
- From unittest.mock
- patch.object
- patch.object with autospec
- using these as context managers
- pytest-mock:
- The mocker fixture
- Cleanup in teardown
- Using mocker.patch, mocker.spy, and mocker.stub
- Why it's awesome and why you might want to use it over straight unittest.mock
Links:
- top pytest plugins list
- pytest-mock documentation
- unittest.mock
- Podcast episode discussing unittest.mock with Michael Foord
- monkeypatch
pytest-mock is a wrapper around unittest.mock.
In this episode:
- Why the pytest-mock plugin is awesome
- What is mocking, patching, and monkey patching
- What, if any, is the difference between mock, fake, spy, stub.
- Why we might need these in testing
- Some history of mock in Python and how mock became unittest.mock
- From unittest.mock
- patch.object
- patch.object with autospec
- using these as context managers
- pytest-mock:
- The mocker fixture
- Cleanup in teardown
- Using mocker.patch, mocker.spy, and mocker.stub
- Why it's awesome and why you might want to use it over straight unittest.mock
Links:
- top pytest plugins list
- pytest-mock documentation
- unittest.mock
- Podcast episode discussing unittest.mock with Michael Foord
- monkeypatch
In this episode, we'll discuss:
- what Coverage.py is
- why you should measure code coverage on both your source and test code
- what pytest-cov is
- extra features pytest-cov gives you over and above coverage.py
- and generally why using both is awesome
Links:
Errata:
- I mentioned that Coverage has the ability to show context (which line is covered by which test) for the past year or so.
- However, that feature was released in Oct 2018. coverage 5.0 alpha
- That's over 6 years. Oops. Sorry Ned.
In this episode, we'll discuss:
- what Coverage.py is
- why you should measure code coverage on both your source and test code
- what pytest-cov is
- extra features pytest-cov gives you over and above coverage.py
- and generally why using both is awesome
Links:
Errata:
- I mentioned that Coverage has the ability to show context (which line is covered by which test) for the past year or so.
- However, that feature was released in Oct 2018. coverage 5.0 alpha
- That's over 6 years. Oops. Sorry Ned.
In this episode, we'll discuss:
- what Coverage.py is
- why you should measure code coverage on both your source and test code
- what pytest-cov is
- extra features pytest-cov gives you over and above coverage.py
- and generally why using both is awesome
Links:
Errata:
- I mentioned that Coverage has the ability to show context (which line is covered by which test) for the past year or so.
- However, that feature was released in Oct 2018. coverage 5.0 alpha
- That's over 6 years. Oops. Sorry Ned.
In this episode:
- Introduction to pytest plugins
- The pytest.org pytest plugin list
- Finding pytest related packages on PyPI
- The Top pytest plugins list on pythontest.com
- Exploring popular plugins
- Learning from plugin examples
Links:
- Top pytest plugins list
- pytest.org plugin list
- Top PyPI Packages
- And links to plugins mentioned in the show can be found at pythontest.com/top-pytest-plugins
In this episode:
- Introduction to pytest plugins
- The pytest.org pytest plugin list
- Finding pytest related packages on PyPI
- The Top pytest plugins list on pythontest.com
- Exploring popular plugins
- Learning from plugin examples
Links:
- Top pytest plugins list
- pytest.org plugin list
- Top PyPI Packages
- And links to plugins mentioned in the show can be found at pythontest.com/top-pytest-plugins
In this episode:
- Introduction to pytest plugins
- The pytest.org pytest plugin list
- Finding pytest related packages on PyPI
- The Top pytest plugins list on pythontest.com
- Exploring popular plugins
- Learning from plugin examples
Links:
- Top pytest plugins list
- pytest.org plugin list
- Top PyPI Packages
- And links to plugins mentioned in the show can be found at pythontest.com/top-pytest-plugins
This episode discusses
- the benefits of writing things down
- preparing for a meeting
- taking notes in meetings
- reviewing notes for action items, todo items, things to follow up on, etc.
- taking notes to allow for better focus
- writing well structured emails
- writing blog posts and books
This episode discusses
- the benefits of writing things down
- preparing for a meeting
- taking notes in meetings
- reviewing notes for action items, todo items, things to follow up on, etc.
- taking notes to allow for better focus
- writing well structured emails
- writing blog posts and books
This episode discusses
- the benefits of writing things down
- preparing for a meeting
- taking notes in meetings
- reviewing notes for action items, todo items, things to follow up on, etc.
- taking notes to allow for better focus
- writing well structured emails
- writing blog posts and books
We'll look at: `from . import module` and `from .module import something`
and also: `import package` to access the external API from with the package.
Why would we use `import package` if `from . import api` would work fine?
We'll look at: `from . import module` and `from .module import something`
and also: `import package` to access the external API from with the package.
Why would we use `import package` if `from . import api` would work fine?
We'll look at: `from . import module` and `from .module import something`
and also: `import package` to access the external API from with the package.
Why would we use `import package` if `from . import api` would work fine?
The tests need to be able to import the code under test, or at least the API to it, in order to run tests against it.
How do we do that? How do we set things up so that our tests can import our code?
In this episode, we discuss two options:
- Installing the code under test as a pip installable package with `pip install -e /path/to/local/package`.
- Using the pythonpath pytest setting.
The tests need to be able to import the code under test, or at least the API to it, in order to run tests against it.
How do we do that? How do we set things up so that our tests can import our code?
In this episode, we discuss two options:
- Installing the code under test as a pip installable package with `pip install -e /path/to/local/package`.
- Using the pythonpath pytest setting.
The tests need to be able to import the code under test, or at least the API to it, in order to run tests against it.
How do we do that? How do we set things up so that our tests can import our code?
In this episode, we discuss two options:
- Installing the code under test as a pip installable package with `pip install -e /path/to/local/package`.
- Using the pythonpath pytest setting.
Even if you never get a chance to go to PyCon, I hope this interview helps you get a feel for the welcoming aspect of the Python community.
I recorded this interview as an episode for one of my other podcasts, Python People. But I think it's got some great pre-conference advice, so I'm sharing it here on Python Test as well.
We talk about:
- Juggling at PyCon
- How to get the most out of PyCon
- Watching talks
- Hallway track
- Open spaces
- Lightening talks
- Expo hall / vendor space
- Poster sessions
- Job fair
- A welcoming community
- Tutorials
- Sprints
- But mostly about the people of Python and PyCon.
"Python enables smart people to work faster" - Rob Ludwick
Even if you never get a chance to go to PyCon, I hope this interview helps you get a feel for the welcoming aspect of the Python community.
I recorded this interview as an episode for one of my other podcasts, Python People. But I think it's got some great pre-conference advice, so I'm sharing it here on Python Test as well.
We talk about:
- Juggling at PyCon
- How to get the most out of PyCon
- Watching talks
- Hallway track
- Open spaces
- Lightening talks
- Expo hall / vendor space
- Poster sessions
- Job fair
- A welcoming community
- Tutorials
- Sprints
- But mostly about the people of Python and PyCon.
"Python enables smart people to work faster" - Rob Ludwick
Even if you never get a chance to go to PyCon, I hope this interview helps you get a feel for the welcoming aspect of the Python community.
I recorded this interview as an episode for one of my other podcasts, Python People. But I think it's got some great pre-conference advice, so I'm sharing it here on Python Test as well.
We talk about:
- Juggling at PyCon
- How to get the most out of PyCon
- Watching talks
- Hallway track
- Open spaces
- Lightening talks
- Expo hall / vendor space
- Poster sessions
- Job fair
- A welcoming community
- Tutorials
- Sprints
- But mostly about the people of Python and PyCon.
"Python enables smart people to work faster" - Rob Ludwick
To help me navigate these decisions, I've brought on Cory Zue.
Cory is the creator of SaaS Pegasus, and has tons of experience with Django.
Some of the topics discussed:
- Building Django applications
- SaaS Pegasus
- placecard.me
- What boilerplate projects are
- Django cookiecutter
- Cookiecutter
- Which database to use, probably PostgreSQL
- Authentication choises, probably Allauth
- Docker, Docker for development, Docker for deployment
- Deployment targets / hosting services. Render, Heroku, Fly.io, for PaaS options.
- Front end frameworks. Bootstrap, Tailwind, DaisyUI, TailwindUI
- HTMX vs React vs straight Django templates
- Rockets
- Font Awesome
- and of course, SaaS Pegasus
To help me navigate these decisions, I've brought on Cory Zue.
Cory is the creator of SaaS Pegasus, and has tons of experience with Django.
Some of the topics discussed:
- Building Django applications
- SaaS Pegasus
- placecard.me
- What boilerplate projects are
- Django cookiecutter
- Cookiecutter
- Which database to use, probably PostgreSQL
- Authentication choises, probably Allauth
- Docker, Docker for development, Docker for deployment
- Deployment targets / hosting services. Render, Heroku, Fly.io, for PaaS options.
- Front end frameworks. Bootstrap, Tailwind, DaisyUI, TailwindUI
- HTMX vs React vs straight Django templates
- Rockets
- Font Awesome
- and of course, SaaS Pegasus
To help me navigate these decisions, I've brought on Cory Zue.
Cory is the creator of SaaS Pegasus, and has tons of experience with Django.
Some of the topics discussed:
- Building Django applications
- SaaS Pegasus
- placecard.me
- What boilerplate projects are
- Django cookiecutter
- Cookiecutter
- Which database to use, probably PostgreSQL
- Authentication choises, probably Allauth
- Docker, Docker for development, Docker for deployment
- Deployment targets / hosting services. Render, Heroku, Fly.io, for PaaS options.
- Front end frameworks. Bootstrap, Tailwind, DaisyUI, TailwindUI
- HTMX vs React vs straight Django templates
- Rockets
- Font Awesome
- and of course, SaaS Pegasus
We talk about:
- Balancing schedule vs testing
- How much testing is the right about of testing
- Should code coverage be measured and tracked
- Good refactoring can reduce code coverage
- Is it worth testing error conditions?
- Are rare error codes ok to just monitor?
- API drift and autospec
- Mitigating risk
- Deciding what to test and what not to test
- Focus testing on key money-making features
- If there's a bug in this part of the code, how much business impact is there?
- Performance testing needs to approximately match real world workloads
- Cost of a service breaking vs the cost of creating, maintaining, and running tests
- Keeping test suites quick to minimize getting distracted
Links:
- Too much of a good thing: the trade-off we make with tests
- Load testing is hard, and the tools are... not great. But why?
- Yet Another Rust Resource (YARR!)
- Goodhart's law - "When a measure becomes a target, it ceases to be a good measure"
We talk about:
- Balancing schedule vs testing
- How much testing is the right about of testing
- Should code coverage be measured and tracked
- Good refactoring can reduce code coverage
- Is it worth testing error conditions?
- Are rare error codes ok to just monitor?
- API drift and autospec
- Mitigating risk
- Deciding what to test and what not to test
- Focus testing on key money-making features
- If there's a bug in this part of the code, how much business impact is there?
- Performance testing needs to approximately match real world workloads
- Cost of a service breaking vs the cost of creating, maintaining, and running tests
- Keeping test suites quick to minimize getting distracted
Links:
- Too much of a good thing: the trade-off we make with tests
- Load testing is hard, and the tools are... not great. But why?
- Yet Another Rust Resource (YARR!)
- Goodhart's law - "When a measure becomes a target, it ceases to be a good measure"
We talk about:
- Balancing schedule vs testing
- How much testing is the right about of testing
- Should code coverage be measured and tracked
- Good refactoring can reduce code coverage
- Is it worth testing error conditions?
- Are rare error codes ok to just monitor?
- API drift and autospec
- Mitigating risk
- Deciding what to test and what not to test
- Focus testing on key money-making features
- If there's a bug in this part of the code, how much business impact is there?
- Performance testing needs to approximately match real world workloads
- Cost of a service breaking vs the cost of creating, maintaining, and running tests
- Keeping test suites quick to minimize getting distracted
Links:
- Too much of a good thing: the trade-off we make with tests
- Load testing is hard, and the tools are... not great. But why?
- Yet Another Rust Resource (YARR!)
- Goodhart's law - "When a measure becomes a target, it ceases to be a good measure"
Justin is one of the people who motivated me to get started podcasting.
He's also running a successful SaaS company, transistor.fm, which hosts this podcast.
Topics:
- Podcasting
- Building new SaaS (software as a service) products
- Balancing work, side hustle, and family
- Great places to snowboard in British Columbia
BTW.
Links from the show:
- Transistor.fm - excellent podcast hosting, Justin is a co-founder
- How to start a podcast in 2024
- Podcasts from Justin
- Build your SaaS - current
- Build & Launch - an older one, but great
- MegaMaker - from 2021 / 2022
Justin is one of the people who motivated me to get started podcasting.
He's also running a successful SaaS company, transistor.fm, which hosts this podcast.
Topics:
- Podcasting
- Building new SaaS (software as a service) products
- Balancing work, side hustle, and family
- Great places to snowboard in British Columbia
BTW.
Links from the show:
- Transistor.fm - excellent podcast hosting, Justin is a co-founder
- How to start a podcast in 2024
- Podcasts from Justin
- Build your SaaS - current
- Build & Launch - an older one, but great
- MegaMaker - from 2021 / 2022
Justin is one of the people who motivated me to get started podcasting.
He's also running a successful SaaS company, transistor.fm, which hosts this podcast.
Topics:
- Podcasting
- Building new SaaS (software as a service) products
- Balancing work, side hustle, and family
- Great places to snowboard in British Columbia
BTW.
Links from the show:
- Transistor.fm - excellent podcast hosting, Justin is a co-founder
- How to start a podcast in 2024
- Podcasts from Justin
- Build your SaaS - current
- Build & Launch - an older one, but great
- MegaMaker - from 2021 / 2022
- Ruff can take the place of Flake8, isort, and Black, and so much more.
- uv can take the place of pip, pip-tools, and virtualenv
- Astral is Charlie's venture backed company, and what they have with `ruff` and `uv` is just the start.
Since uv is the newest tool, there's quite a bit of the discussion diving into uv.
Links:
- Ruff can take the place of Flake8, isort, and Black, and so much more.
- uv can take the place of pip, pip-tools, and virtualenv
- Astral is Charlie's venture backed company, and what they have with `ruff` and `uv` is just the start.
Since uv is the newest tool, there's quite a bit of the discussion diving into uv.
Links:
- Ruff can take the place of Flake8, isort, and Black, and so much more.
- uv can take the place of pip, pip-tools, and virtualenv
- Astral is Charlie's venture backed company, and what they have with `ruff` and `uv` is just the start.
Since uv is the newest tool, there's quite a bit of the discussion diving into uv.
Links:
Matt Makai went from individual contributor to developer relations to leadership in devrel.
We discuss how to stay technical, as well as dive into some results of his studies in how companies use developer relationship channels.
Matt Makai went from individual contributor to developer relations to leadership in devrel.
We discuss how to stay technical, as well as dive into some results of his studies in how companies use developer relationship channels.
Matt Makai went from individual contributor to developer relations to leadership in devrel.
We discuss how to stay technical, as well as dive into some results of his studies in how companies use developer relationship channels.
The Python for VS Code interface for testing, especially for pytest, has changed recently.
On this episode we discuss the change with the software engineer working on the pytest changes, Eleanor Boyd, and the product manager, Courtney Webster.
Links from the episode:
The Python for VS Code interface for testing, especially for pytest, has changed recently.
On this episode we discuss the change with the software engineer working on the pytest changes, Eleanor Boyd, and the product manager, Courtney Webster.
Links from the episode:
The Python for VS Code interface for testing, especially for pytest, has changed recently.
On this episode we discuss the change with the software engineer working on the pytest changes, Eleanor Boyd, and the product manager, Courtney Webster.
Links from the episode:
There are a few pytest plugins that help with this:
We talk about each of these in this episode.
There are a few pytest plugins that help with this:
We talk about each of these in this episode.
There are a few pytest plugins that help with this:
We talk about each of these in this episode.
In December of 2023, Kent wrote an article called "Canon TDD".
With Kent's permission, this episode contains the full content of the article.
Brian's commentary is saved for a followup episode.
Links:
In December of 2023, Kent wrote an article called "Canon TDD".
With Kent's permission, this episode contains the full content of the article.
Brian's commentary is saved for a followup episode.
Links:
In December of 2023, Kent wrote an article called "Canon TDD".
With Kent's permission, this episode contains the full content of the article.
Brian's commentary is saved for a followup episode.
Links:
If the behavior is different in isolation vs in a suite, it's a nightmare to debug.
In this episode, we'll talk about:
- Causes of dependence
- Testing for dependencies using plugins
- Debugging test dependencies
Plugins discussed:
- pytest-randomly
- pytest-reverse
- pytest-random-order
If the behavior is different in isolation vs in a suite, it's a nightmare to debug.
In this episode, we'll talk about:
- Causes of dependence
- Testing for dependencies using plugins
- Debugging test dependencies
Plugins discussed:
- pytest-randomly
- pytest-reverse
- pytest-random-order
If the behavior is different in isolation vs in a suite, it's a nightmare to debug.
In this episode, we'll talk about:
- Causes of dependence
- Testing for dependencies using plugins
- Debugging test dependencies
Plugins discussed:
- pytest-randomly
- pytest-reverse
- pytest-random-order
- Do we have to do the refactor part?
- Does the refactor at the end include tests?
- Or can I refactor the tests at any time?
- Why is refactor at the end?
This episode is to talk about this with a an example.
- Do we have to do the refactor part?
- Does the refactor at the end include tests?
- Or can I refactor the tests at any time?
- Why is refactor at the end?
This episode is to talk about this with a an example.
- Do we have to do the refactor part?
- Does the refactor at the end include tests?
- Or can I refactor the tests at any time?
- Why is refactor at the end?
This episode is to talk about this with a an example.
This episode covers:
- Design for Test: Structuring your app or script so it's easier to test.
- pytest & capsys for testing stdout
- Adding debug and preview flags for debugging and testing
- And reverting to subprocess.run if you can't modify the code under test
Also, there's a full writeup and code samples available:
- Blog post: Testing argparse Applications
- Code Repo
This episode covers:
- Design for Test: Structuring your app or script so it's easier to test.
- pytest & capsys for testing stdout
- Adding debug and preview flags for debugging and testing
- And reverting to subprocess.run if you can't modify the code under test
Also, there's a full writeup and code samples available:
- Blog post: Testing argparse Applications
- Code Repo
This episode covers:
- Design for Test: Structuring your app or script so it's easier to test.
- pytest & capsys for testing stdout
- Adding debug and preview flags for debugging and testing
- And reverting to subprocess.run if you can't modify the code under test
Also, there's a full writeup and code samples available:
- Blog post: Testing argparse Applications
- Code Repo
After all, aren't assert statements how you decide wether a test passes or fails?
In this episode, we walk through a handful of useful examples of test code without asserts.
We also talk about how these types of tests are a great way to dip your toe into testing.
After all, aren't assert statements how you decide wether a test passes or fails?
In this episode, we walk through a handful of useful examples of test code without asserts.
We also talk about how these types of tests are a great way to dip your toe into testing.
After all, aren't assert statements how you decide wether a test passes or fails?
In this episode, we walk through a handful of useful examples of test code without asserts.
We also talk about how these types of tests are a great way to dip your toe into testing.
- Give `--repeat-scope` a try. You can use it to change from repeating every test to repeating the session, module, or class.
- Give `--repeat-scope` a try. You can use it to change from repeating every test to repeating the session, module, or class.
- Give `--repeat-scope` a try. You can use it to change from repeating every test to repeating the session, module, or class.
However, software tools and available CI systems have changed quite a bit since then.
Maybe it's time to re-examine the assumptions, practices, processes, and principles of TDD.
At least in the context of my software engineering career, modifications to TDD, at least the version of TDD as it's frequently taught, have been necessary.
This is the start of a series focused on examining TDD and related lightweight practices and processes.
Links from the show:
However, software tools and available CI systems have changed quite a bit since then.
Maybe it's time to re-examine the assumptions, practices, processes, and principles of TDD.
At least in the context of my software engineering career, modifications to TDD, at least the version of TDD as it's frequently taught, have been necessary.
This is the start of a series focused on examining TDD and related lightweight practices and processes.
Links from the show:
However, software tools and available CI systems have changed quite a bit since then.
Maybe it's time to re-examine the assumptions, practices, processes, and principles of TDD.
At least in the context of my software engineering career, modifications to TDD, at least the version of TDD as it's frequently taught, have been necessary.
This is the start of a series focused on examining TDD and related lightweight practices and processes.
Links from the show:
In this episode, we describe:
- what fixtures are
- what autouse fixtures are
- great reasons to use them
In this episode, we describe:
- what fixtures are
- what autouse fixtures are
- great reasons to use them
In this episode, we describe:
- what fixtures are
- what autouse fixtures are
- great reasons to use them
Johanna Rothman joins the show to discuss writing nonfiction.
Johanna's book: Free Your Inner Nonfiction Writer
Johanna Rothman joins the show to discuss writing nonfiction.
Johanna's book: Free Your Inner Nonfiction Writer
Johanna Rothman joins the show to discuss writing nonfiction.
Johanna's book: Free Your Inner Nonfiction Writer
Joe Curley, vice president and general manager of software products and ecosystem, and Arun Gupta, vice president and general manager for open ecosystems, join the show to discuss open source, OneAPI, and open ecosystems at Intel.
Joe Curley, vice president and general manager of software products and ecosystem, and Arun Gupta, vice president and general manager for open ecosystems, join the show to discuss open source, OneAPI, and open ecosystems at Intel.
Joe Curley, vice president and general manager of software products and ecosystem, and Arun Gupta, vice president and general manager for open ecosystems, join the show to discuss open source, OneAPI, and open ecosystems at Intel.
At the top of the towncrier documentation, it says "towncrier is a utility to produce useful, summarized news files (also known as changelogs) for your project."
Towncrier is used by "Twisted, pytest, pip, BuildBot, and attrs, among others."
This is the last of 3 episodes focused on keeping a CHANGELOG.
Episode 200 kicked off the series with keepachangelog.com and Olivier Lacan
In 201 we had Ned Batchelder discussing scriv.
Special Guest: Hynek Schlawack.
Links:
- Towncrier docs
- How to Keep a Changelog in Markdown - Towncrier docs
- Keep a Changelog
- structlog/CHANGELOG.md — Example of manually edited changelog.
- hatch-fancy-pypi-readme
- MyST Markdown
- hatchling
At the top of the towncrier documentation, it says "towncrier is a utility to produce useful, summarized news files (also known as changelogs) for your project."
Towncrier is used by "Twisted, pytest, pip, BuildBot, and attrs, among others."
This is the last of 3 episodes focused on keeping a CHANGELOG.
Episode 200 kicked off the series with keepachangelog.com and Olivier Lacan
In 201 we had Ned Batchelder discussing scriv.
Special Guest: Hynek Schlawack.
Links:
- Towncrier docs
- How to Keep a Changelog in Markdown - Towncrier docs
- Keep a Changelog
- structlog/CHANGELOG.md — Example of manually edited changelog.
- hatch-fancy-pypi-readme
- MyST Markdown
- hatchling
At the top of the towncrier documentation, it says "towncrier is a utility to produce useful, summarized news files (also known as changelogs) for your project."
Towncrier is used by "Twisted, pytest, pip, BuildBot, and attrs, among others."
This is the last of 3 episodes focused on keeping a CHANGELOG.
Episode 200 kicked off the series with keepachangelog.com and Olivier Lacan
In 201 we had Ned Batchelder discussing scriv.
Special Guest: Hynek Schlawack.
Links:
- Towncrier docs
- How to Keep a Changelog in Markdown - Towncrier docs
- Keep a Changelog
- structlog/CHANGELOG.md — Example of manually edited changelog.
- hatch-fancy-pypi-readme
- MyST Markdown
- hatchling
This week we talk with Ned Batchelder about scriv, a tool to help maintain that changelog.
Scriv "is a command-line tool for helping developers maintain useful changelogs. It manages a directory of changelog fragments. It aggregates them into entries in a CHANGELOG file."
Links:
This week we talk with Ned Batchelder about scriv, a tool to help maintain that changelog.
Scriv "is a command-line tool for helping developers maintain useful changelogs. It manages a directory of changelog fragments. It aggregates them into entries in a CHANGELOG file."
Links:
This week we talk with Ned Batchelder about scriv, a tool to help maintain that changelog.
Scriv "is a command-line tool for helping developers maintain useful changelogs. It manages a directory of changelog fragments. It aggregates them into entries in a CHANGELOG file."
Links:
This episode is about what a changelog is, with an interview with Olivier Lacan, creator of keepachangelog.com.
The next two episodes talk about some tools to help software project teams keep changelogs while avoiding merge conflicts.
Special Guest: Olivier Lacan.
Links:
- Shields.io
- Keep a Changelog
- "The Changelog" Podcast interview with Olivier Lacan
- An Open Source Rage Diamond
This episode is about what a changelog is, with an interview with Olivier Lacan, creator of keepachangelog.com.
The next two episodes talk about some tools to help software project teams keep changelogs while avoiding merge conflicts.
Special Guest: Olivier Lacan.
Links:
- Shields.io
- Keep a Changelog
- "The Changelog" Podcast interview with Olivier Lacan
- An Open Source Rage Diamond
This episode is about what a changelog is, with an interview with Olivier Lacan, creator of keepachangelog.com.
The next two episodes talk about some tools to help software project teams keep changelogs while avoiding merge conflicts.
Special Guest: Olivier Lacan.
Links:
- Shields.io
- Keep a Changelog
- "The Changelog" Podcast interview with Olivier Lacan
- An Open Source Rage Diamond
Pamela Fox, a Cloud Advocate for Python at Microsoft, joins the show to help us with that question.
Links:
- Python Bytes Episode #323
- pamelafox gitHub projects
- Deploy a Python (Django or Flask) web app to Azure
- Hosting Python Web Apps on Azure: A Price-Off
- Deploying a containerized FastAPI app to Azure Container Apps
- Getting started with hosting Python apps on Azure
- Pricing Calculator for Azure
- App Service Pricing
- pamelafox/flask-db-quiz-example
- Tutorial: Deploy a Python Django or Flask web app with PostgreSQL
- Pamela Fox on Mastodon
Pamela Fox, a Cloud Advocate for Python at Microsoft, joins the show to help us with that question.
Links:
- Python Bytes Episode #323
- pamelafox gitHub projects
- Deploy a Python (Django or Flask) web app to Azure
- Hosting Python Web Apps on Azure: A Price-Off
- Deploying a containerized FastAPI app to Azure Container Apps
- Getting started with hosting Python apps on Azure
- Pricing Calculator for Azure
- App Service Pricing
- pamelafox/flask-db-quiz-example
- Tutorial: Deploy a Python Django or Flask web app with PostgreSQL
- Pamela Fox on Mastodon
Pamela Fox, a Cloud Advocate for Python at Microsoft, joins the show to help us with that question.
Links:
- Python Bytes Episode #323
- pamelafox gitHub projects
- Deploy a Python (Django or Flask) web app to Azure
- Hosting Python Web Apps on Azure: A Price-Off
- Deploying a containerized FastAPI app to Azure Container Apps
- Getting started with hosting Python apps on Azure
- Pricing Calculator for Azure
- App Service Pricing
- pamelafox/flask-db-quiz-example
- Tutorial: Deploy a Python Django or Flask web app with PostgreSQL
- Pamela Fox on Mastodon
Classifiers are weird.
They were around in setuptools days, and are still here with pyproject.toml.
- What are they?
- Why do we need them?
- Do we need them?
- Which classifiers should I include?
- Why are they called "trove classifiers" in the Python docs
Brett Cannon joins the show to discuss these wacky bits of metadata.
Here's an example, from pytest-crayons:
[project] ... classifiers = [ "License :: OSI Approved :: MIT License", "Framework :: Pytest" ]Links:
- Classifiers · PyPI
- PEP 621 – Storing project metadata in pyproject.toml | peps.python.org
- Packaging Python Projects — Python Packaging User Guide — Configuring metadata
- PEP 639 – Improving License Clarity with Better Package Metadata | peps.python.org
- SPDX
Classifiers are weird.
They were around in setuptools days, and are still here with pyproject.toml.
- What are they?
- Why do we need them?
- Do we need them?
- Which classifiers should I include?
- Why are they called "trove classifiers" in the Python docs
Brett Cannon joins the show to discuss these wacky bits of metadata.
Here's an example, from pytest-crayons:
[project] ... classifiers = [ "License :: OSI Approved :: MIT License", "Framework :: Pytest" ]Links:
- Classifiers · PyPI
- PEP 621 – Storing project metadata in pyproject.toml | peps.python.org
- Packaging Python Projects — Python Packaging User Guide — Configuring metadata
- PEP 639 – Improving License Clarity with Better Package Metadata | peps.python.org
- SPDX
Classifiers are weird.
They were around in setuptools days, and are still here with pyproject.toml.
- What are they?
- Why do we need them?
- Do we need them?
- Which classifiers should I include?
- Why are they called "trove classifiers" in the Python docs
Brett Cannon joins the show to discuss these wacky bits of metadata.
Here's an example, from pytest-crayons:
[project] ... classifiers = [ "License :: OSI Approved :: MIT License", "Framework :: Pytest" ]Links:
- Classifiers · PyPI
- PEP 621 – Storing project metadata in pyproject.toml | peps.python.org
- Packaging Python Projects — Python Packaging User Guide — Configuring metadata
- PEP 639 – Improving License Clarity with Better Package Metadata | peps.python.org
- SPDX
There are problems with supply chain analogy when applied to software.
Thomas Depierre discusses some of those issues in this episode.
Links:
There are problems with supply chain analogy when applied to software.
Thomas Depierre discusses some of those issues in this episode.
Links:
There are problems with supply chain analogy when applied to software.
Thomas Depierre discusses some of those issues in this episode.
Links:
Anthony's list:
- The import system
- Multi-process support out of the box
- Async support
- Changes to the fixture system
- Extend the assert rewriting to make it modular
- Add matchers to assert mechanism
- Ban test class inheritance
Brian's list:
- Extend assert rewriting for custom rewriting, like check
- pytester matchers available for all tests
- Throw out nose and unittest compatibility plugins
- Throw out setup_module, teardown_module and other xunit style functions
- Remove a bunch of the hook functions
- Documentation improvement of remaining hook functions which include examples of how to use it
- Start running tests before collection is done
- Split collection and running into two processes
- Have the fixtures be able to know the result of the test during teardown
Links:
- anthonywritescode - YouTube
- anthonywritescode - Twitch
- pytest-asyncio · PyPI
- async test patterns for pytest
- future-fstrings · PyPI
- re-assert · PyPI
- numpy.testing
- Sourcegraph
Anthony's list:
- The import system
- Multi-process support out of the box
- Async support
- Changes to the fixture system
- Extend the assert rewriting to make it modular
- Add matchers to assert mechanism
- Ban test class inheritance
Brian's list:
- Extend assert rewriting for custom rewriting, like check
- pytester matchers available for all tests
- Throw out nose and unittest compatibility plugins
- Throw out setup_module, teardown_module and other xunit style functions
- Remove a bunch of the hook functions
- Documentation improvement of remaining hook functions which include examples of how to use it
- Start running tests before collection is done
- Split collection and running into two processes
- Have the fixtures be able to know the result of the test during teardown
Links:
- anthonywritescode - YouTube
- anthonywritescode - Twitch
- pytest-asyncio · PyPI
- async test patterns for pytest
- future-fstrings · PyPI
- re-assert · PyPI
- numpy.testing
- Sourcegraph
Anthony's list:
- The import system
- Multi-process support out of the box
- Async support
- Changes to the fixture system
- Extend the assert rewriting to make it modular
- Add matchers to assert mechanism
- Ban test class inheritance
Brian's list:
- Extend assert rewriting for custom rewriting, like check
- pytester matchers available for all tests
- Throw out nose and unittest compatibility plugins
- Throw out setup_module, teardown_module and other xunit style functions
- Remove a bunch of the hook functions
- Documentation improvement of remaining hook functions which include examples of how to use it
- Start running tests before collection is done
- Split collection and running into two processes
- Have the fixtures be able to know the result of the test during teardown
Links:
- anthonywritescode - YouTube
- anthonywritescode - Twitch
- pytest-asyncio · PyPI
- async test patterns for pytest
- future-fstrings · PyPI
- re-assert · PyPI
- numpy.testing
- Sourcegraph
From astronomy, to neuroscience, to chemistry, to climate models.
If you work in research that hasn't been affected by software yet, just wait.
But how good is that software?
How much of common best practices in software development are making it to those writing software in the sciences?
Patrick Mineault has written "The Good Research Code Handbook".
It's a website. It's concise.
And it will put you on the right path to writing better software.
Even if you don't write science based software, and even if you already have a CS degree, there's some good information worth reading.
Special Guest: Patrick Mineault.
Links:
- The Good Research Code Handbook
- game-wrath-jam: A game jam game, theme: Wrath
- Robotron 2084 - Arcade - YouTube
- The Book of Why: The New Science of Cause and Effect
From astronomy, to neuroscience, to chemistry, to climate models.
If you work in research that hasn't been affected by software yet, just wait.
But how good is that software?
How much of common best practices in software development are making it to those writing software in the sciences?
Patrick Mineault has written "The Good Research Code Handbook".
It's a website. It's concise.
And it will put you on the right path to writing better software.
Even if you don't write science based software, and even if you already have a CS degree, there's some good information worth reading.
Special Guest: Patrick Mineault.
Links:
- The Good Research Code Handbook
- game-wrath-jam: A game jam game, theme: Wrath
- Robotron 2084 - Arcade - YouTube
- The Book of Why: The New Science of Cause and Effect
From astronomy, to neuroscience, to chemistry, to climate models.
If you work in research that hasn't been affected by software yet, just wait.
But how good is that software?
How much of common best practices in software development are making it to those writing software in the sciences?
Patrick Mineault has written "The Good Research Code Handbook".
It's a website. It's concise.
And it will put you on the right path to writing better software.
Even if you don't write science based software, and even if you already have a CS degree, there's some good information worth reading.
Special Guest: Patrick Mineault.
Links:
- The Good Research Code Handbook
- game-wrath-jam: A game jam game, theme: Wrath
- Robotron 2084 - Arcade - YouTube
- The Book of Why: The New Science of Cause and Effect
Learning to code a game is a way that a lot of people get started and excited about programming.
Of course, I don't recommend Basic. Now we've got Python. And one of the game engines available for Python is PursuedPyBear, a project started by Piper Thunstrom.
Piper joins us this episode and we talk about PursuedPyBear, learning to code, and learning CS concepts with game development.
PursuedPyBear, ppb, is a game framework great for learning with, with goals of being fun, education friendly, an example of idiomatic Python, hardware library agnostic, and built on event driven and object oriented concepts.
Special Guest: Piper Thunstrom.
Links:
- PursuedPyBear | Unbearably Fun Game Development
- Piper's Blog
- Making Games With PPB - PyTexas
- Shooter Game by Piper Thunstrom
- shootergame on GitHub
- Briefcase— BeeWare
- game-blink: A tiny emergent behavior toy.
- Combat (Atari 2600) — The tank game I didn't remember the name of.
- Lunar Lander
Learning to code a game is a way that a lot of people get started and excited about programming.
Of course, I don't recommend Basic. Now we've got Python. And one of the game engines available for Python is PursuedPyBear, a project started by Piper Thunstrom.
Piper joins us this episode and we talk about PursuedPyBear, learning to code, and learning CS concepts with game development.
PursuedPyBear, ppb, is a game framework great for learning with, with goals of being fun, education friendly, an example of idiomatic Python, hardware library agnostic, and built on event driven and object oriented concepts.
Special Guest: Piper Thunstrom.
Links:
- PursuedPyBear | Unbearably Fun Game Development
- Piper's Blog
- Making Games With PPB - PyTexas
- Shooter Game by Piper Thunstrom
- shootergame on GitHub
- Briefcase— BeeWare
- game-blink: A tiny emergent behavior toy.
- Combat (Atari 2600) — The tank game I didn't remember the name of.
- Lunar Lander
Learning to code a game is a way that a lot of people get started and excited about programming.
Of course, I don't recommend Basic. Now we've got Python. And one of the game engines available for Python is PursuedPyBear, a project started by Piper Thunstrom.
Piper joins us this episode and we talk about PursuedPyBear, learning to code, and learning CS concepts with game development.
PursuedPyBear, ppb, is a game framework great for learning with, with goals of being fun, education friendly, an example of idiomatic Python, hardware library agnostic, and built on event driven and object oriented concepts.
Special Guest: Piper Thunstrom.
Links:
- PursuedPyBear | Unbearably Fun Game Development
- Piper's Blog
- Making Games With PPB - PyTexas
- Shooter Game by Piper Thunstrom
- shootergame on GitHub
- Briefcase— BeeWare
- game-blink: A tiny emergent behavior toy.
- Combat (Atari 2600) — The tank game I didn't remember the name of.
- Lunar Lander
Links:
- Random Geekery
- Jamstack
- Eleventy
- Netlify
- Plausible Analytics
- pytest
- Beautiful Soup
- pyinvoke - Invoke!
- rsync
- Internet Archive : archive.org
- Rich
- Statamic
- jamstack.org
- A static site generator should be your next language learning project
Links:
- Random Geekery
- Jamstack
- Eleventy
- Netlify
- Plausible Analytics
- pytest
- Beautiful Soup
- pyinvoke - Invoke!
- rsync
- Internet Archive : archive.org
- Rich
- Statamic
- jamstack.org
- A static site generator should be your next language learning project
Links:
- Random Geekery
- Jamstack
- Eleventy
- Netlify
- Plausible Analytics
- pytest
- Beautiful Soup
- pyinvoke - Invoke!
- rsync
- Internet Archive : archive.org
- Rich
- Statamic
- jamstack.org
- A static site generator should be your next language learning project
cPython is implemented in C.
PyPy is implemented in Python.
What does that mean?
And how do you test something as huge as an alternative implementation of Python?
Special Guest: Carl Friedrich Bolz-Tereick.
Links:
cPython is implemented in C.
PyPy is implemented in Python.
What does that mean?
And how do you test something as huge as an alternative implementation of Python?
Special Guest: Carl Friedrich Bolz-Tereick.
Links:
cPython is implemented in C.
PyPy is implemented in Python.
What does that mean?
And how do you test something as huge as an alternative implementation of Python?
Special Guest: Carl Friedrich Bolz-Tereick.
Links:
Before attrs, it wasn't pretty.
The story of attrs and dataclasses is actually intertwined.
They've built on each other.
And in the middle of it all, Hynek.
Hynek joins the show today to discuss some history of attrs and dataclasses, and some differences.
If you ever need to create a custom class in Python, you should listen to this episode.
Links:
- attrs documentation
- History of attrs and introduction to attrs namespace
- cattrs: Complex custom class converters for attrs. — python-attrs
- PEP 557 – Data Classes
- PEP 681 – Data Class Transforms
Before attrs, it wasn't pretty.
The story of attrs and dataclasses is actually intertwined.
They've built on each other.
And in the middle of it all, Hynek.
Hynek joins the show today to discuss some history of attrs and dataclasses, and some differences.
If you ever need to create a custom class in Python, you should listen to this episode.
Links:
- attrs documentation
- History of attrs and introduction to attrs namespace
- cattrs: Complex custom class converters for attrs. — python-attrs
- PEP 557 – Data Classes
- PEP 681 – Data Class Transforms
Before attrs, it wasn't pretty.
The story of attrs and dataclasses is actually intertwined.
They've built on each other.
And in the middle of it all, Hynek.
Hynek joins the show today to discuss some history of attrs and dataclasses, and some differences.
If you ever need to create a custom class in Python, you should listen to this episode.
Links:
- attrs documentation
- History of attrs and introduction to attrs namespace
- cattrs: Complex custom class converters for attrs. — python-attrs
- PEP 557 – Data Classes
- PEP 681 – Data Class Transforms
Then Textual started rethinking full command line applications, including layout with CSS.
And now Textualize, a new startup, is bringing CLI apps to the web.
Links:
Then Textual started rethinking full command line applications, including layout with CSS.
And now Textualize, a new startup, is bringing CLI apps to the web.
Links:
Then Textual started rethinking full command line applications, including layout with CSS.
And now Textualize, a new startup, is bringing CLI apps to the web.
Links:
Karl Stolley believes it's never too early. Let's hear how he incorporates code quality in his courses.
Our discussion includes:
- starting people off with good dev practices and tools
- linting
- html and css validation
- visual regression testing
- using local dev servers, including https
- incorporating testing with git hooks
- testing to aid in css optimization and refactoring
- Backstop
- Nightwatch
- BrowserStack
- the tree legged stool of learning and progressing as a developer: testing, version control, and documentation
Karl is also writing a book on WebRTC, so we jump into that a bit too.
Links:
- Backstop
- Nightwatch
- BrowserStack
- Programming WebRTC: Build Real-Time Streaming Applications for the Web by Karl Stolley
Karl Stolley believes it's never too early. Let's hear how he incorporates code quality in his courses.
Our discussion includes:
- starting people off with good dev practices and tools
- linting
- html and css validation
- visual regression testing
- using local dev servers, including https
- incorporating testing with git hooks
- testing to aid in css optimization and refactoring
- Backstop
- Nightwatch
- BrowserStack
- the tree legged stool of learning and progressing as a developer: testing, version control, and documentation
Karl is also writing a book on WebRTC, so we jump into that a bit too.
Links:
- Backstop
- Nightwatch
- BrowserStack
- Programming WebRTC: Build Real-Time Streaming Applications for the Web by Karl Stolley
Karl Stolley believes it's never too early. Let's hear how he incorporates code quality in his courses.
Our discussion includes:
- starting people off with good dev practices and tools
- linting
- html and css validation
- visual regression testing
- using local dev servers, including https
- incorporating testing with git hooks
- testing to aid in css optimization and refactoring
- Backstop
- Nightwatch
- BrowserStack
- the tree legged stool of learning and progressing as a developer: testing, version control, and documentation
Karl is also writing a book on WebRTC, so we jump into that a bit too.
Links:
- Backstop
- Nightwatch
- BrowserStack
- Programming WebRTC: Build Real-Time Streaming Applications for the Web by Karl Stolley
Can we measure it?
Should we measure it?
There's been failed attempts, like lines of code, etc. in the past.
Currently, there are new tools to measure productivity, like using git metrics.
Nick Hodges joins the show to discuss the good and the bad of developer and team productivity, including how we can improve productivity.
Can we measure it?
Should we measure it?
There's been failed attempts, like lines of code, etc. in the past.
Currently, there are new tools to measure productivity, like using git metrics.
Nick Hodges joins the show to discuss the good and the bad of developer and team productivity, including how we can improve productivity.
Can we measure it?
Should we measure it?
There's been failed attempts, like lines of code, etc. in the past.
Currently, there are new tools to measure productivity, like using git metrics.
Nick Hodges joins the show to discuss the good and the bad of developer and team productivity, including how we can improve productivity.
django-rich adds color and nice formatting. Super cool.
In a recent release, django-rich also adds nice colorized tracebacks to the Django test runner.
Links:
- django-rich · PyPI
- episode 181: Boost Your Django DX - Adam Johnson
- django-crispy-forms
- Python Developers Survey 2020 Results
django-rich adds color and nice formatting. Super cool.
In a recent release, django-rich also adds nice colorized tracebacks to the Django test runner.
Links:
- django-rich · PyPI
- episode 181: Boost Your Django DX - Adam Johnson
- django-crispy-forms
- Python Developers Survey 2020 Results
django-rich adds color and nice formatting. Super cool.
In a recent release, django-rich also adds nice colorized tracebacks to the Django test runner.
Links:
- django-rich · PyPI
- episode 181: Boost Your Django DX - Adam Johnson
- django-crispy-forms
- Python Developers Survey 2020 Results
Twisted uses a technique that should be usable by other applications, even those using asyncio or other event driven architectures.
Links:
- Community Service Award Recipient Glyph Lefkowitz — The PSF article I was referring to early in the episode
- Twisted
- twisted/klein
- twisted/treq
- django/daphne — Django Channels HTTP/WebSocket server
- Scrapy
- So Easy You Can Even Do It in JavaScript: Event-Driven Architecture for Regular Programmers - YouTube
- Feature test - twitter engineering
- Python Testing with pytest — Some reading for Glyph if he wants to learn to love pytest
- pytest-twisted
- pygame
- Pyodide
- Brython
Twisted uses a technique that should be usable by other applications, even those using asyncio or other event driven architectures.
Links:
- Community Service Award Recipient Glyph Lefkowitz — The PSF article I was referring to early in the episode
- Twisted
- twisted/klein
- twisted/treq
- django/daphne — Django Channels HTTP/WebSocket server
- Scrapy
- So Easy You Can Even Do It in JavaScript: Event-Driven Architecture for Regular Programmers - YouTube
- Feature test - twitter engineering
- Python Testing with pytest — Some reading for Glyph if he wants to learn to love pytest
- pytest-twisted
- pygame
- Pyodide
- Brython
Twisted uses a technique that should be usable by other applications, even those using asyncio or other event driven architectures.
Links:
- Community Service Award Recipient Glyph Lefkowitz — The PSF article I was referring to early in the episode
- Twisted
- twisted/klein
- twisted/treq
- django/daphne — Django Channels HTTP/WebSocket server
- Scrapy
- So Easy You Can Even Do It in JavaScript: Event-Driven Architecture for Regular Programmers - YouTube
- Feature test - twitter engineering
- Python Testing with pytest — Some reading for Glyph if he wants to learn to love pytest
- pytest-twisted
- pygame
- Pyodide
- Brython
We end up talking about a lot of skills that are excellent for software engineers as well as managers.
Some topics discussed:
- handling code reviews
- asking good questions
- being honest about what you can't do with current resources and data
- discussing tradeoffs and offering solutions that can be completed faster than the ideal solution
- balancing engineering and managing
- making sure documentation happens
- remote teams
- encouraging collaboration
- encouraging non-work-related conversations
- watching out for overworking
We end up talking about a lot of skills that are excellent for software engineers as well as managers.
Some topics discussed:
- handling code reviews
- asking good questions
- being honest about what you can't do with current resources and data
- discussing tradeoffs and offering solutions that can be completed faster than the ideal solution
- balancing engineering and managing
- making sure documentation happens
- remote teams
- encouraging collaboration
- encouraging non-work-related conversations
- watching out for overworking
We end up talking about a lot of skills that are excellent for software engineers as well as managers.
Some topics discussed:
- handling code reviews
- asking good questions
- being honest about what you can't do with current resources and data
- discussing tradeoffs and offering solutions that can be completed faster than the ideal solution
- balancing engineering and managing
- making sure documentation happens
- remote teams
- encouraging collaboration
- encouraging non-work-related conversations
- watching out for overworking
No? Neither does Nathan Aschbacher.
So when he started building the team at his company, he decided to do things differently.
Hiring is one of the essential processes for building a great team.
However, it's a high noise, low signal process.
Nathan Aschbacher has a relatively unorthodox tech hiring approach.
He's trying to make it very humane, with a better signal to noise ratio.
Nathan is not intereseted in bizarre interview processes where the interviewer doesn't know anything about the interviewee beforehand, all people are asked the same questions, and people are asked to code on white boards.
Instead, he states "if the goal is to try to figure out if the person can do the work with your team, and your trying to build the team that you are adding this person to, they need to know what the team is like, and determine if they want to be part of the team, and the team needs to know what the person is like and if they would be addititve to the team.
So what's Nathan's process:
- Screening resumes and CVs, looking for internal motivation to become an expert at something.
- Basic phone screen, very informal.
- A couple 2-3 hour pairings with someone on the team with whatever they are working on.
- Debriefing both the candidate and the team afterwords.
- Giving the candidate an opportunity for a second impression and following up on difficulties during the pairings.
We discuss the process, and also:
- trying to remove the barriers to team integration
- treating people as humans
And of course, there's the story of how Nathan ended up interviewing someone with Zoo experience an no technical experience for a technical role. Of course, it was a misunderstanding of a job requirement around experience with ZooKeeper. But it's a good story.
No? Neither does Nathan Aschbacher.
So when he started building the team at his company, he decided to do things differently.
Hiring is one of the essential processes for building a great team.
However, it's a high noise, low signal process.
Nathan Aschbacher has a relatively unorthodox tech hiring approach.
He's trying to make it very humane, with a better signal to noise ratio.
Nathan is not intereseted in bizarre interview processes where the interviewer doesn't know anything about the interviewee beforehand, all people are asked the same questions, and people are asked to code on white boards.
Instead, he states "if the goal is to try to figure out if the person can do the work with your team, and your trying to build the team that you are adding this person to, they need to know what the team is like, and determine if they want to be part of the team, and the team needs to know what the person is like and if they would be addititve to the team.
So what's Nathan's process:
- Screening resumes and CVs, looking for internal motivation to become an expert at something.
- Basic phone screen, very informal.
- A couple 2-3 hour pairings with someone on the team with whatever they are working on.
- Debriefing both the candidate and the team afterwords.
- Giving the candidate an opportunity for a second impression and following up on difficulties during the pairings.
We discuss the process, and also:
- trying to remove the barriers to team integration
- treating people as humans
And of course, there's the story of how Nathan ended up interviewing someone with Zoo experience an no technical experience for a technical role. Of course, it was a misunderstanding of a job requirement around experience with ZooKeeper. But it's a good story.
No? Neither does Nathan Aschbacher.
So when he started building the team at his company, he decided to do things differently.
Hiring is one of the essential processes for building a great team.
However, it's a high noise, low signal process.
Nathan Aschbacher has a relatively unorthodox tech hiring approach.
He's trying to make it very humane, with a better signal to noise ratio.
Nathan is not intereseted in bizarre interview processes where the interviewer doesn't know anything about the interviewee beforehand, all people are asked the same questions, and people are asked to code on white boards.
Instead, he states "if the goal is to try to figure out if the person can do the work with your team, and your trying to build the team that you are adding this person to, they need to know what the team is like, and determine if they want to be part of the team, and the team needs to know what the person is like and if they would be addititve to the team.
So what's Nathan's process:
- Screening resumes and CVs, looking for internal motivation to become an expert at something.
- Basic phone screen, very informal.
- A couple 2-3 hour pairings with someone on the team with whatever they are working on.
- Debriefing both the candidate and the team afterwords.
- Giving the candidate an opportunity for a second impression and following up on difficulties during the pairings.
We discuss the process, and also:
- trying to remove the barriers to team integration
- treating people as humans
And of course, there's the story of how Nathan ended up interviewing someone with Zoo experience an no technical experience for a technical role. Of course, it was a misunderstanding of a job requirement around experience with ZooKeeper. But it's a good story.
Developer experience includes tools and practices to make developers more effective and efficient, and just plain make software development more fun and satisfying.
One of the things I love about this book is that it's not just for Django devs.
I'd guess that about half the book is about topics that all Python developers would find useful, from virtual environments to linters to testing.
But of course, also tons of tips and tools for working with Django.
Links:
- “Boost Your Django DX” Released — Adam's announcement
- Boost Your Django DX — The book
Developer experience includes tools and practices to make developers more effective and efficient, and just plain make software development more fun and satisfying.
One of the things I love about this book is that it's not just for Django devs.
I'd guess that about half the book is about topics that all Python developers would find useful, from virtual environments to linters to testing.
But of course, also tons of tips and tools for working with Django.
Links:
- “Boost Your Django DX” Released — Adam's announcement
- Boost Your Django DX — The book
Developer experience includes tools and practices to make developers more effective and efficient, and just plain make software development more fun and satisfying.
One of the things I love about this book is that it's not just for Django devs.
I'd guess that about half the book is about topics that all Python developers would find useful, from virtual environments to linters to testing.
But of course, also tons of tips and tools for working with Django.
Links:
- “Boost Your Django DX” Released — Adam's announcement
- Boost Your Django DX — The book
I've mentioned Lean TDD on the podcast a few times and even tried to do a quick outline at the end of episode 162.
This episode is a more complete outline, or at least a first draft.
If you feel you've got a good understanding of TDD, and it's working awesome for you, that's great. Keep doing what you're doing. There are no problems.
For me, the normal way TDD is taught just doesn't work. So I'm trying to come up with a spin on some old ideas to make it work for me. I'm hoping it works for you as well.
I'm calling the new thing Lean TDD. It's inspired by decades of experience writing software and influence from dozens of sources, including Pragmatic Programmer, Lean Software Development, Test-Driven Development by Example, and many blog posts and wiki articles.
The main highlights, however, come from the collision of ideas between Lean and TDD and how I've tried to resolve the seemingly opposing processes.
Links:
- Lean TDD | pythontest.com
- episode 162: Flavors of TDD
- What is Test Driven Development (TDD)? | Agile Alliance
- Test First Programming / Test First Development | pythontest.com
- episode 7: The Waterfall Model and “Managing the Development of Large Software Systems”
- episode 51: Feature Testing
- The testing renaissance — Twitter Engineering blog post about Feature Testing
- Lean software development - Wikipedia
I've mentioned Lean TDD on the podcast a few times and even tried to do a quick outline at the end of episode 162.
This episode is a more complete outline, or at least a first draft.
If you feel you've got a good understanding of TDD, and it's working awesome for you, that's great. Keep doing what you're doing. There are no problems.
For me, the normal way TDD is taught just doesn't work. So I'm trying to come up with a spin on some old ideas to make it work for me. I'm hoping it works for you as well.
I'm calling the new thing Lean TDD. It's inspired by decades of experience writing software and influence from dozens of sources, including Pragmatic Programmer, Lean Software Development, Test-Driven Development by Example, and many blog posts and wiki articles.
The main highlights, however, come from the collision of ideas between Lean and TDD and how I've tried to resolve the seemingly opposing processes.
Links:
- Lean TDD | pythontest.com
- episode 162: Flavors of TDD
- What is Test Driven Development (TDD)? | Agile Alliance
- Test First Programming / Test First Development | pythontest.com
- episode 7: The Waterfall Model and “Managing the Development of Large Software Systems”
- episode 51: Feature Testing
- The testing renaissance — Twitter Engineering blog post about Feature Testing
- Lean software development - Wikipedia
I've mentioned Lean TDD on the podcast a few times and even tried to do a quick outline at the end of episode 162.
This episode is a more complete outline, or at least a first draft.
If you feel you've got a good understanding of TDD, and it's working awesome for you, that's great. Keep doing what you're doing. There are no problems.
For me, the normal way TDD is taught just doesn't work. So I'm trying to come up with a spin on some old ideas to make it work for me. I'm hoping it works for you as well.
I'm calling the new thing Lean TDD. It's inspired by decades of experience writing software and influence from dozens of sources, including Pragmatic Programmer, Lean Software Development, Test-Driven Development by Example, and many blog posts and wiki articles.
The main highlights, however, come from the collision of ideas between Lean and TDD and how I've tried to resolve the seemingly opposing processes.
Links:
- Lean TDD | pythontest.com
- episode 162: Flavors of TDD
- What is Test Driven Development (TDD)? | Agile Alliance
- Test First Programming / Test First Development | pythontest.com
- episode 7: The Waterfall Model and “Managing the Development of Large Software Systems”
- episode 51: Feature Testing
- The testing renaissance — Twitter Engineering blog post about Feature Testing
- Lean software development - Wikipedia
This episode discusses what exploratory testing is, its benefits, and how it fits within a framework of relying on automated tests for most of our testing.
This episode discusses what exploratory testing is, its benefits, and how it fits within a framework of relying on automated tests for most of our testing.
This episode discusses what exploratory testing is, its benefits, and how it fits within a framework of relying on automated tests for most of our testing.
This episode discusses the factors.
Sarah's order:
- Verify the code is working correctly
- Prevent future regressions
- Document the code’s behavior
- Provide design guidance
- Support refactoring
Brian's order:
- Verify the code is working correctly
- Prevent future regressions
- Support refactoring
- Provide design guidance
- Document the code’s behavior
The episode includes reasons why I've re-ordered them.
Links:
This episode discusses the factors.
Sarah's order:
- Verify the code is working correctly
- Prevent future regressions
- Document the code’s behavior
- Provide design guidance
- Support refactoring
Brian's order:
- Verify the code is working correctly
- Prevent future regressions
- Support refactoring
- Provide design guidance
- Document the code’s behavior
The episode includes reasons why I've re-ordered them.
Links:
This episode discusses the factors.
Sarah's order:
- Verify the code is working correctly
- Prevent future regressions
- Document the code’s behavior
- Provide design guidance
- Support refactoring
Brian's order:
- Verify the code is working correctly
- Prevent future regressions
- Support refactoring
- Provide design guidance
- Document the code’s behavior
The episode includes reasons why I've re-ordered them.
Links:
This discussion is about the distinction between unit and integration tests, what those terms mean, and where we should spend our testing time.
Links:
- Simon Willison's Twitter Thread
- The Testing Trophy and Testing Classifications — Kent C Dodds
- Write tests. Not too many. Mostly integration. — Kent C Dodds
- On the Diverse And Fantastical Shapes of Testing — Martin Fowler
This discussion is about the distinction between unit and integration tests, what those terms mean, and where we should spend our testing time.
Links:
- Simon Willison's Twitter Thread
- The Testing Trophy and Testing Classifications — Kent C Dodds
- Write tests. Not too many. Mostly integration. — Kent C Dodds
- On the Diverse And Fantastical Shapes of Testing — Martin Fowler
This discussion is about the distinction between unit and integration tests, what those terms mean, and where we should spend our testing time.
Links:
- Simon Willison's Twitter Thread
- The Testing Trophy and Testing Classifications — Kent C Dodds
- Write tests. Not too many. Mostly integration. — Kent C Dodds
- On the Diverse And Fantastical Shapes of Testing — Martin Fowler
Solve a problem with software. Have a nice looking landing page and website. Get paying customers.
Eventually have it make enough revenue so you can turn it into your primary source of income.
There's a lot of software talent out there. We could solve lots of problems.
But going from idea to product to first customer is non-trivial.
Especially as a side hustle.
This episode discusses some of the hurdles from idea to first customer.
Brandon Braner is building Released.sh. It's a cool idea, but it's not done yet.
Brandon and I talk about building side projects:
- finding a target audience
- limiting scope to something doable by one person
- building a great looking landing page
- finding time to work on things
- prioritizing and planning
- learning while building
- even utilizing third party services to allow you to launch faster
- and last, but not least, having fun
Special Guest: Brandon Braner.
Links:
Solve a problem with software. Have a nice looking landing page and website. Get paying customers.
Eventually have it make enough revenue so you can turn it into your primary source of income.
There's a lot of software talent out there. We could solve lots of problems.
But going from idea to product to first customer is non-trivial.
Especially as a side hustle.
This episode discusses some of the hurdles from idea to first customer.
Brandon Braner is building Released.sh. It's a cool idea, but it's not done yet.
Brandon and I talk about building side projects:
- finding a target audience
- limiting scope to something doable by one person
- building a great looking landing page
- finding time to work on things
- prioritizing and planning
- learning while building
- even utilizing third party services to allow you to launch faster
- and last, but not least, having fun
Special Guest: Brandon Braner.
Links:
Solve a problem with software. Have a nice looking landing page and website. Get paying customers.
Eventually have it make enough revenue so you can turn it into your primary source of income.
There's a lot of software talent out there. We could solve lots of problems.
But going from idea to product to first customer is non-trivial.
Especially as a side hustle.
This episode discusses some of the hurdles from idea to first customer.
Brandon Braner is building Released.sh. It's a cool idea, but it's not done yet.
Brandon and I talk about building side projects:
- finding a target audience
- limiting scope to something doable by one person
- building a great looking landing page
- finding time to work on things
- prioritizing and planning
- learning while building
- even utilizing third party services to allow you to launch faster
- and last, but not least, having fun
Special Guest: Brandon Braner.
Links:
Answering these questions are the goals of this episode.
Links:
Answering these questions are the goals of this episode.
Links:
Answering these questions are the goals of this episode.
Links:
Pseudo-TDD is a way to keep your commit history clean and your tests passing with each commit.
This workflow includes using pytest xfail and some semi-advanced version control features.
Some strict forms of TDD include something like this:
- write a failing test that demonstrates a lacking feature or defect
- write the source code to get the test to pass
- refactor if necessary
- repeat
In reality, at least for me, the software development process is way more messy than this, and not so smooth and linear.
Pauls workflow allow you to develop non-linearly, but commit cleanly.
Links:
- A pseudo-TDD workflow using expected failures
- episode 171: How and why I use pytest's xfail - Paul Ganssle
- episode 165: pytest xfail policy and workflow
- episode 162: Flavors of TDD
Pseudo-TDD is a way to keep your commit history clean and your tests passing with each commit.
This workflow includes using pytest xfail and some semi-advanced version control features.
Some strict forms of TDD include something like this:
- write a failing test that demonstrates a lacking feature or defect
- write the source code to get the test to pass
- refactor if necessary
- repeat
In reality, at least for me, the software development process is way more messy than this, and not so smooth and linear.
Pauls workflow allow you to develop non-linearly, but commit cleanly.
Links:
- A pseudo-TDD workflow using expected failures
- episode 171: How and why I use pytest's xfail - Paul Ganssle
- episode 165: pytest xfail policy and workflow
- episode 162: Flavors of TDD
Pseudo-TDD is a way to keep your commit history clean and your tests passing with each commit.
This workflow includes using pytest xfail and some semi-advanced version control features.
Some strict forms of TDD include something like this:
- write a failing test that demonstrates a lacking feature or defect
- write the source code to get the test to pass
- refactor if necessary
- repeat
In reality, at least for me, the software development process is way more messy than this, and not so smooth and linear.
Pauls workflow allow you to develop non-linearly, but commit cleanly.
Links:
- A pseudo-TDD workflow using expected failures
- episode 171: How and why I use pytest's xfail - Paul Ganssle
- episode 165: pytest xfail policy and workflow
- episode 162: Flavors of TDD
unittest is an xUnit style framework. For me, xUnit style frameworks are fatally flawed for software testing.
That's what this episode is about, my opinion of
- "Why NOT unittest?", or more broadly,
- "What are the fatal flaws of xUnit?"
Links:
unittest is an xUnit style framework. For me, xUnit style frameworks are fatally flawed for software testing.
That's what this episode is about, my opinion of
- "Why NOT unittest?", or more broadly,
- "What are the fatal flaws of xUnit?"
Links:
unittest is an xUnit style framework. For me, xUnit style frameworks are fatally flawed for software testing.
That's what this episode is about, my opinion of
- "Why NOT unittest?", or more broadly,
- "What are the fatal flaws of xUnit?"
Links:
In software, we think of prototypes as early things, or a proof of concept.
We don't often think of prototyping during daily software development or maintenance. I think we should.
This episode is about growing better designed software with the help of a prototype mindset.
Links:
- Selecting a programming language can be a form of premature optimization — Brett Cannon's blog post
In software, we think of prototypes as early things, or a proof of concept.
We don't often think of prototyping during daily software development or maintenance. I think we should.
This episode is about growing better designed software with the help of a prototype mindset.
Links:
- Selecting a programming language can be a form of premature optimization — Brett Cannon's blog post
In software, we think of prototypes as early things, or a proof of concept.
We don't often think of prototyping during daily software development or maintenance. I think we should.
This episode is about growing better designed software with the help of a prototype mindset.
Links:
- Selecting a programming language can be a form of premature optimization — Brett Cannon's blog post
He was an early skeptic of using xfail, and is now an proponent of the feature.
In this episode, we talk about some open source workflows that are possible because of xfail.
Special Guest: Paul Ganssle.
Links:
- How and why I use pytest's xfail — Paul's blog post mentioned in the episode
- Craft Minimal Bug Reports — Matthew Rocklin's article
- episode 111: Subtests in Python with unittest and pytest - Paul Ganssle
- episode 165: pytest xfail policy and workflow
- episode 166: unittest expectedFailure and xfail
He was an early skeptic of using xfail, and is now an proponent of the feature.
In this episode, we talk about some open source workflows that are possible because of xfail.
Special Guest: Paul Ganssle.
Links:
- How and why I use pytest's xfail — Paul's blog post mentioned in the episode
- Craft Minimal Bug Reports — Matthew Rocklin's article
- episode 111: Subtests in Python with unittest and pytest - Paul Ganssle
- episode 165: pytest xfail policy and workflow
- episode 166: unittest expectedFailure and xfail
He was an early skeptic of using xfail, and is now an proponent of the feature.
In this episode, we talk about some open source workflows that are possible because of xfail.
Special Guest: Paul Ganssle.
Links:
- How and why I use pytest's xfail — Paul's blog post mentioned in the episode
- Craft Minimal Bug Reports — Matthew Rocklin's article
- episode 111: Subtests in Python with unittest and pytest - Paul Ganssle
- episode 165: pytest xfail policy and workflow
- episode 166: unittest expectedFailure and xfail
Prayson is using pytest for some pretty cool stuff, including:
- unit tests, of course
- testing pipeline stages
- counterfactual testing
- performance testing
All with pytest. So cool.
Special Guest: Prayson Daniel.
Links:
- Python Bytes 250, with Prayson Daniel — Listen to this for more of an introduction to Prayson
Prayson is using pytest for some pretty cool stuff, including:
- unit tests, of course
- testing pipeline stages
- counterfactual testing
- performance testing
All with pytest. So cool.
Special Guest: Prayson Daniel.
Links:
- Python Bytes 250, with Prayson Daniel — Listen to this for more of an introduction to Prayson
Prayson is using pytest for some pretty cool stuff, including:
- unit tests, of course
- testing pipeline stages
- counterfactual testing
- performance testing
All with pytest. So cool.
Special Guest: Prayson Daniel.
Links:
- Python Bytes 250, with Prayson Daniel — Listen to this for more of an introduction to Prayson
Special Guest: Omri Sass.
Special Guest: Omri Sass.
Special Guest: Omri Sass.
We discuss workflow and the differences, similarities between testing with React/TypeScript and Python.
We also discuss what lessons that we can bring from front end testing to Python testing.
Special Guest: Paul Everitt.
Links:
- React, TypeScript, and TDD — Paul Everitt's tutorial
- React Testing Library
We discuss workflow and the differences, similarities between testing with React/TypeScript and Python.
We also discuss what lessons that we can bring from front end testing to Python testing.
Special Guest: Paul Everitt.
Links:
- React, TypeScript, and TDD — Paul Everitt's tutorial
- React Testing Library
We discuss workflow and the differences, similarities between testing with React/TypeScript and Python.
We also discuss what lessons that we can bring from front end testing to Python testing.
Special Guest: Paul Everitt.
Links:
- React, TypeScript, and TDD — Paul Everitt's tutorial
- React Testing Library
In this episode, we cover:
- using @unittest.expectedFailure
- the results of passing and failing tests with expectedFailure
- using pytest as a test runner for unittest
- using pytest markers on unittest tests
Docs for expectedFailure:
https://docs.python.org/3/library/unittest.html#skipping-tests-and-expected-failures
Some sample code.
unittest only:
unittest with pytest markers:
import unittest import pytest class ExpectedFailureTestCase(unittest.TestCase): @pytest.mark.xfail def test_fail(self): self.assertEqual(1, 0, "broken") @pytest.mark.xfail def test_pass(self): self.assertEqual(1, 1, "not broken")In this episode, we cover:
- using @unittest.expectedFailure
- the results of passing and failing tests with expectedFailure
- using pytest as a test runner for unittest
- using pytest markers on unittest tests
Docs for expectedFailure:
https://docs.python.org/3/library/unittest.html#skipping-tests-and-expected-failures
Some sample code.
unittest only:
unittest with pytest markers:
import unittest import pytest class ExpectedFailureTestCase(unittest.TestCase): @pytest.mark.xfail def test_fail(self): self.assertEqual(1, 0, "broken") @pytest.mark.xfail def test_pass(self): self.assertEqual(1, 1, "not broken")In this episode, we cover:
- using @unittest.expectedFailure
- the results of passing and failing tests with expectedFailure
- using pytest as a test runner for unittest
- using pytest markers on unittest tests
Docs for expectedFailure:
https://docs.python.org/3/library/unittest.html#skipping-tests-and-expected-failures
Some sample code.
unittest only:
unittest with pytest markers:
import unittest import pytest class ExpectedFailureTestCase(unittest.TestCase): @pytest.mark.xfail def test_fail(self): self.assertEqual(1, 0, "broken") @pytest.mark.xfail def test_pass(self): self.assertEqual(1, 1, "not broken")The episode covers:
- What is xfail
- Why I use it
- Using reason effectively by including issue tracking numbers
- Using xfail_strict
- Adding --runxfail when transitioning from development to feature freeze
- What to do about test failures
- How all of this might help with team communication
The episode covers:
- What is xfail
- Why I use it
- Using reason effectively by including issue tracking numbers
- Using xfail_strict
- Adding --runxfail when transitioning from development to feature freeze
- What to do about test failures
- How all of this might help with team communication
The episode covers:
- What is xfail
- Why I use it
- Using reason effectively by including issue tracking numbers
- Using xfail_strict
- Adding --runxfail when transitioning from development to feature freeze
- What to do about test failures
- How all of this might help with team communication
From Chapter 13, Debugging Test Failures, of Python Testing with pytest, 2nd edition.
pytest includes quite a few command-line flags that are useful for debugging.
We talk about thes flags in this episode.
Flags for selecting which tests to run, in which order, and when to stop:
- -lf / --last-failed: Runs just the tests that failed last.
- -ff / --failed-failed: Runs all the tests, starting with the last failed.
- -x / --exitfirst: Stops the tests session afterEd: after?Author: yep the first failure.
- --maxfail=num: Stops the tests after num failures.
- -nf / --new-first: Runs all the tests, ordered by file modification time.
- --sw / --stepwise: Stops the tests at the first failure. Starts the tests at the last failure next time.
- --sw-skip / --stepwise-skip: Same as --sw, but skips the first failure.
Flags to control pytest output:
- -v / --verbose Displays all the test names, passing or failing.
- --tb=[auto/long/short/line/native/no] Controls the traceback style.
- -l / --showlocals Displays local variables alongside the stacktrace.
Flags to start a command-line debugger:
- --pdb Starts an interactive debugging session at the point of failure.
- --trace Starts the pdb source-code debugger immediately when running each test.
- --pdbcls Uses alternatives to pdb, such as IPython’s debugger with –-pdbcls=IPython.terminal.debugger:TerminalPdb.
This list is also found in Chapter 13 of Python Testing with pytest, 2nd edition.
The chapter is "Debugging Test Failures" and covers way more than just debug flags, while walking through debugging 2 test failures.
Links:
- Python Testing with pytest — The fastest way to get up to speed on pytest.
- all pytest flags in pytest 6.2.x
From Chapter 13, Debugging Test Failures, of Python Testing with pytest, 2nd edition.
pytest includes quite a few command-line flags that are useful for debugging.
We talk about thes flags in this episode.
Flags for selecting which tests to run, in which order, and when to stop:
- -lf / --last-failed: Runs just the tests that failed last.
- -ff / --failed-failed: Runs all the tests, starting with the last failed.
- -x / --exitfirst: Stops the tests session afterEd: after?Author: yep the first failure.
- --maxfail=num: Stops the tests after num failures.
- -nf / --new-first: Runs all the tests, ordered by file modification time.
- --sw / --stepwise: Stops the tests at the first failure. Starts the tests at the last failure next time.
- --sw-skip / --stepwise-skip: Same as --sw, but skips the first failure.
Flags to control pytest output:
- -v / --verbose Displays all the test names, passing or failing.
- --tb=[auto/long/short/line/native/no] Controls the traceback style.
- -l / --showlocals Displays local variables alongside the stacktrace.
Flags to start a command-line debugger:
- --pdb Starts an interactive debugging session at the point of failure.
- --trace Starts the pdb source-code debugger immediately when running each test.
- --pdbcls Uses alternatives to pdb, such as IPython’s debugger with –-pdbcls=IPython.terminal.debugger:TerminalPdb.
This list is also found in Chapter 13 of Python Testing with pytest, 2nd edition.
The chapter is "Debugging Test Failures" and covers way more than just debug flags, while walking through debugging 2 test failures.
Links:
- Python Testing with pytest — The fastest way to get up to speed on pytest.
- all pytest flags in pytest 6.2.x
From Chapter 13, Debugging Test Failures, of Python Testing with pytest, 2nd edition.
pytest includes quite a few command-line flags that are useful for debugging.
We talk about thes flags in this episode.
Flags for selecting which tests to run, in which order, and when to stop:
- -lf / --last-failed: Runs just the tests that failed last.
- -ff / --failed-failed: Runs all the tests, starting with the last failed.
- -x / --exitfirst: Stops the tests session afterEd: after?Author: yep the first failure.
- --maxfail=num: Stops the tests after num failures.
- -nf / --new-first: Runs all the tests, ordered by file modification time.
- --sw / --stepwise: Stops the tests at the first failure. Starts the tests at the last failure next time.
- --sw-skip / --stepwise-skip: Same as --sw, but skips the first failure.
Flags to control pytest output:
- -v / --verbose Displays all the test names, passing or failing.
- --tb=[auto/long/short/line/native/no] Controls the traceback style.
- -l / --showlocals Displays local variables alongside the stacktrace.
Flags to start a command-line debugger:
- --pdb Starts an interactive debugging session at the point of failure.
- --trace Starts the pdb source-code debugger immediately when running each test.
- --pdbcls Uses alternatives to pdb, such as IPython’s debugger with –-pdbcls=IPython.terminal.debugger:TerminalPdb.
This list is also found in Chapter 13 of Python Testing with pytest, 2nd edition.
The chapter is "Debugging Test Failures" and covers way more than just debug flags, while walking through debugging 2 test failures.
Links:
- Python Testing with pytest — The fastest way to get up to speed on pytest.
- all pytest flags in pytest 6.2.x
pip is an invaluable tool when developing with Python.
A lot of people know pip as a way to install third party packages from pypi.org
You can also use pip to install from other indexes (or is it indices?)
You can also use pip to install a package in a local directory.
That's the part I want to jump in and explore with Stéphane Bidoul.
The way pip installs from a local directory is about to change, and the story is fascinating.
Special Guest: Stéphane Bidoul.
Links:
- The Odoo Community Association
- PEP 610 -- Recording the Direct URL Origin of installed distributions | Python.org
- PEP 660 -- Editable installs for pyproject.toml based builds (wheel based) | Python.org — Bidoul
- pip install --no-index --find-links
- Solving issues related to out-of-tree builds · Issue #7555 · pypa/pip
- pip list json format
pip is an invaluable tool when developing with Python.
A lot of people know pip as a way to install third party packages from pypi.org
You can also use pip to install from other indexes (or is it indices?)
You can also use pip to install a package in a local directory.
That's the part I want to jump in and explore with Stéphane Bidoul.
The way pip installs from a local directory is about to change, and the story is fascinating.
Special Guest: Stéphane Bidoul.
Links:
- The Odoo Community Association
- PEP 610 -- Recording the Direct URL Origin of installed distributions | Python.org
- PEP 660 -- Editable installs for pyproject.toml based builds (wheel based) | Python.org — Bidoul
- pip install --no-index --find-links
- Solving issues related to out-of-tree builds · Issue #7555 · pypa/pip
- pip list json format
pip is an invaluable tool when developing with Python.
A lot of people know pip as a way to install third party packages from pypi.org
You can also use pip to install from other indexes (or is it indices?)
You can also use pip to install a package in a local directory.
That's the part I want to jump in and explore with Stéphane Bidoul.
The way pip installs from a local directory is about to change, and the story is fascinating.
Special Guest: Stéphane Bidoul.
Links:
- The Odoo Community Association
- PEP 610 -- Recording the Direct URL Origin of installed distributions | Python.org
- PEP 660 -- Editable installs for pyproject.toml based builds (wheel based) | Python.org — Bidoul
- pip install --no-index --find-links
- Solving issues related to out-of-tree builds · Issue #7555 · pypa/pip
- pip list json format
In this episode we talk about:
- Classical vs Mockist TDD
- Detroit vs London (I actually refer to it in the episode as Chicago instead of Detroit. Oh well.)
- Static vs Behavior
- Inside Out vs Outside In
- Double Loop TDD
- BDD
- FDD
- Tracer Bullets
- Rules of TDD
- Team Structure
- Lean TDD
This is definitely an episode I'd like feedback on. Reach out to me for further questions or if I missed some crucial variant of TDD that you know and love.
Links:
- Mocks Aren't Stubs - Martin Fowler
- Mockists Are Dead. Long Live Classicists.
- Double Loop TDD
- BDD: Behavior-driven development
- FDD: Feature-driven development
- My reaction to “Is TDD Dead?” - pythontest.com
- Test First Programming / Test First Development
- Humorous list of TDD variants — BDD = Buzzword Driven Development, CDD = Calendar Driven Development, etc
In this episode we talk about:
- Classical vs Mockist TDD
- Detroit vs London (I actually refer to it in the episode as Chicago instead of Detroit. Oh well.)
- Static vs Behavior
- Inside Out vs Outside In
- Double Loop TDD
- BDD
- FDD
- Tracer Bullets
- Rules of TDD
- Team Structure
- Lean TDD
This is definitely an episode I'd like feedback on. Reach out to me for further questions or if I missed some crucial variant of TDD that you know and love.
Links:
- Mocks Aren't Stubs - Martin Fowler
- Mockists Are Dead. Long Live Classicists.
- Double Loop TDD
- BDD: Behavior-driven development
- FDD: Feature-driven development
- My reaction to “Is TDD Dead?” - pythontest.com
- Test First Programming / Test First Development
- Humorous list of TDD variants — BDD = Buzzword Driven Development, CDD = Calendar Driven Development, etc
In this episode we talk about:
- Classical vs Mockist TDD
- Detroit vs London (I actually refer to it in the episode as Chicago instead of Detroit. Oh well.)
- Static vs Behavior
- Inside Out vs Outside In
- Double Loop TDD
- BDD
- FDD
- Tracer Bullets
- Rules of TDD
- Team Structure
- Lean TDD
This is definitely an episode I'd like feedback on. Reach out to me for further questions or if I missed some crucial variant of TDD that you know and love.
Links:
- Mocks Aren't Stubs - Martin Fowler
- Mockists Are Dead. Long Live Classicists.
- Double Loop TDD
- BDD: Behavior-driven development
- FDD: Feature-driven development
- My reaction to “Is TDD Dead?” - pythontest.com
- Test First Programming / Test First Development
- Humorous list of TDD variants — BDD = Buzzword Driven Development, CDD = Calendar Driven Development, etc
Lean manufacturing and lean software development changed the way we look at value and waste.
This episode looks at lean definitions of waste, so we can see it clearly when we encounter it.
I'm going to use the term waste and value in future episodes. I'm using waste in a Lean sense, so we can look at software processes critically, see the value chain, and try to reduce waste.
Lean manufacturing and lean software development caused people to talk about and examine waste and value, even in fields where we didn't really think about waste that much to begin with.
Software is just ones and zeros. Is there waste?
When I delete a file, nothing goes into the landfill.
The mistake I'm making here is confusing the common English definition of waste when what we're talking about is the Lean definition of waste.
This episode tries to clear up the confusion.
Links:
- Big Design Up Front
- Lightweight Methodologies
- Manifesto for Agile Software Development
- Extreme programming
- The New Methodology
- Test First Programming / Test First Development
- Test Driven Development
- The Pragmatic Programmer
- Six Sigma
- DMAIC
- Lean software development
- Lean manufacturing
- The Toyota Way
- Lean Six Sigma
- Definition of Waste by Merriam-Webster
Lean manufacturing and lean software development changed the way we look at value and waste.
This episode looks at lean definitions of waste, so we can see it clearly when we encounter it.
I'm going to use the term waste and value in future episodes. I'm using waste in a Lean sense, so we can look at software processes critically, see the value chain, and try to reduce waste.
Lean manufacturing and lean software development caused people to talk about and examine waste and value, even in fields where we didn't really think about waste that much to begin with.
Software is just ones and zeros. Is there waste?
When I delete a file, nothing goes into the landfill.
The mistake I'm making here is confusing the common English definition of waste when what we're talking about is the Lean definition of waste.
This episode tries to clear up the confusion.
Links:
- Big Design Up Front
- Lightweight Methodologies
- Manifesto for Agile Software Development
- Extreme programming
- The New Methodology
- Test First Programming / Test First Development
- Test Driven Development
- The Pragmatic Programmer
- Six Sigma
- DMAIC
- Lean software development
- Lean manufacturing
- The Toyota Way
- Lean Six Sigma
- Definition of Waste by Merriam-Webster
Lean manufacturing and lean software development changed the way we look at value and waste.
This episode looks at lean definitions of waste, so we can see it clearly when we encounter it.
I'm going to use the term waste and value in future episodes. I'm using waste in a Lean sense, so we can look at software processes critically, see the value chain, and try to reduce waste.
Lean manufacturing and lean software development caused people to talk about and examine waste and value, even in fields where we didn't really think about waste that much to begin with.
Software is just ones and zeros. Is there waste?
When I delete a file, nothing goes into the landfill.
The mistake I'm making here is confusing the common English definition of waste when what we're talking about is the Lean definition of waste.
This episode tries to clear up the confusion.
Links:
- Big Design Up Front
- Lightweight Methodologies
- Manifesto for Agile Software Development
- Extreme programming
- The New Methodology
- Test First Programming / Test First Development
- Test Driven Development
- The Pragmatic Programmer
- Six Sigma
- DMAIC
- Lean software development
- Lean manufacturing
- The Toyota Way
- Lean Six Sigma
- Definition of Waste by Merriam-Webster
How about your test code? Do different rules apply?
Wait, what do all of these acronyms mean?
We'll get to all of these definitions, and then talk about how it applies to both production code and test code in this episode.
Links:
- The Pragmatic Programmer, 20th Anniversary Edition
- Don't repeat yourself - Wikipedia
- a-ha - Take On Me
- Rule of three - Wikipedia
- What does “DAMP not DRY” mean when talking about unit tests? - Stack Overflow
How about your test code? Do different rules apply?
Wait, what do all of these acronyms mean?
We'll get to all of these definitions, and then talk about how it applies to both production code and test code in this episode.
Links:
- The Pragmatic Programmer, 20th Anniversary Edition
- Don't repeat yourself - Wikipedia
- a-ha - Take On Me
- Rule of three - Wikipedia
- What does “DAMP not DRY” mean when talking about unit tests? - Stack Overflow
How about your test code? Do different rules apply?
Wait, what do all of these acronyms mean?
We'll get to all of these definitions, and then talk about how it applies to both production code and test code in this episode.
Links:
- The Pragmatic Programmer, 20th Anniversary Edition
- Don't repeat yourself - Wikipedia
- a-ha - Take On Me
- Rule of three - Wikipedia
- What does “DAMP not DRY” mean when talking about unit tests? - Stack Overflow
Matt Harrison had a great idea: Why not use your own Twitter analytics data?
So, he did that with his own data, and shares what he learned in this episode, including some of his secrets to gaining followers.
In this episode we talk about:
- Looking at your own Twitter analytics data.
- Using Python, pandas, Jupyter for data cleaning and exploratory analysis
- Data visualization
- Machine learning, principal component analysis, clustering
- Model drift and re-running analysis
- What kind of tweets perform well
- And much more
Links:
- Applied Pandas: Twitter Analytics — the course
Matt Harrison had a great idea: Why not use your own Twitter analytics data?
So, he did that with his own data, and shares what he learned in this episode, including some of his secrets to gaining followers.
In this episode we talk about:
- Looking at your own Twitter analytics data.
- Using Python, pandas, Jupyter for data cleaning and exploratory analysis
- Data visualization
- Machine learning, principal component analysis, clustering
- Model drift and re-running analysis
- What kind of tweets perform well
- And much more
Links:
- Applied Pandas: Twitter Analytics — the course
Matt Harrison had a great idea: Why not use your own Twitter analytics data?
So, he did that with his own data, and shares what he learned in this episode, including some of his secrets to gaining followers.
In this episode we talk about:
- Looking at your own Twitter analytics data.
- Using Python, pandas, Jupyter for data cleaning and exploratory analysis
- Data visualization
- Machine learning, principal component analysis, clustering
- Model drift and re-running analysis
- What kind of tweets perform well
- And much more
Links:
- Applied Pandas: Twitter Analytics — the course
All of us that care about developing quality code with the help of testing can learn from each other, regardless of programming language.
Today we step outside our normal Python comfort zone and talk with Gio about TDD in Swift.
Gio Lodi, author of TDD in Swift, joins the show to discuss Test Driven Development, software workflows, bottom up vs top down, rapid feedback, developer vs customer facing tests, and more.
Links:
- TDD in Swift with SwiftUI and Combine
- mokacoding - Gio's blog
- XCTest
- Software Design: Tidy First? - Kent Beck on Substack
All of us that care about developing quality code with the help of testing can learn from each other, regardless of programming language.
Today we step outside our normal Python comfort zone and talk with Gio about TDD in Swift.
Gio Lodi, author of TDD in Swift, joins the show to discuss Test Driven Development, software workflows, bottom up vs top down, rapid feedback, developer vs customer facing tests, and more.
Links:
- TDD in Swift with SwiftUI and Combine
- mokacoding - Gio's blog
- XCTest
- Software Design: Tidy First? - Kent Beck on Substack
All of us that care about developing quality code with the help of testing can learn from each other, regardless of programming language.
Today we step outside our normal Python comfort zone and talk with Gio about TDD in Swift.
Gio Lodi, author of TDD in Swift, joins the show to discuss Test Driven Development, software workflows, bottom up vs top down, rapid feedback, developer vs customer facing tests, and more.
Links:
- TDD in Swift with SwiftUI and Combine
- mokacoding - Gio's blog
- XCTest
- Software Design: Tidy First? - Kent Beck on Substack
Anthony Sottile discusses pre-commit, for using locally by developers, and pre-commit.ci, which can run actions during merge requests.
"Git hook scripts are useful for identifying simple issues before submission to code review. We run our hooks on every commit to automatically point out issues in code such as missing semicolons, trailing whitespace, and debug statements. By pointing these issues out before code review, this allows a code reviewer to focus on the architecture of a change while not wasting time with trivial style nitpicks." - pre-commit.com
"Developers spend a fair chunk of time during their development flow fixing relatively trivial problems in their code. pre-commit.ci both enforces that these issues are discovered, which is opt in for each developer workflow via pre-commit, but also fixes the issues automatically, letting developers focus their time on more valuable problems." - A user of pre-commit.ci
Links:
Anthony Sottile discusses pre-commit, for using locally by developers, and pre-commit.ci, which can run actions during merge requests.
"Git hook scripts are useful for identifying simple issues before submission to code review. We run our hooks on every commit to automatically point out issues in code such as missing semicolons, trailing whitespace, and debug statements. By pointing these issues out before code review, this allows a code reviewer to focus on the architecture of a change while not wasting time with trivial style nitpicks." - pre-commit.com
"Developers spend a fair chunk of time during their development flow fixing relatively trivial problems in their code. pre-commit.ci both enforces that these issues are discovered, which is opt in for each developer workflow via pre-commit, but also fixes the issues automatically, letting developers focus their time on more valuable problems." - A user of pre-commit.ci
Links:
Anthony Sottile discusses pre-commit, for using locally by developers, and pre-commit.ci, which can run actions during merge requests.
"Git hook scripts are useful for identifying simple issues before submission to code review. We run our hooks on every commit to automatically point out issues in code such as missing semicolons, trailing whitespace, and debug statements. By pointing these issues out before code review, this allows a code reviewer to focus on the architecture of a change while not wasting time with trivial style nitpicks." - pre-commit.com
"Developers spend a fair chunk of time during their development flow fixing relatively trivial problems in their code. pre-commit.ci both enforces that these issues are discovered, which is opt in for each developer workflow via pre-commit, but also fixes the issues automatically, letting developers focus their time on more valuable problems." - A user of pre-commit.ci
Links:
By default, it includes lint checks provided Pyflakes, pycodestyle, and McCabe
It's also a platform, and allows plugins to extend the checks.
Flake8 will run third-party extensions if they are found and installed.
But what does all of that mean?
Anthony Sottile is a maintainer of flake8 and has kindly offered to explain it to us.
Links:
- Flake8: Your Tool For Style Guide Enforcement
- pyflakes
- pycodestyle
- mccabe
- pyflakes/messages.py
- flake8 Error / Violation Codes
- wemake-python-styleguide
- flake8-typing-imports
- tox automation project
- Nox
- pre-commit
By default, it includes lint checks provided Pyflakes, pycodestyle, and McCabe
It's also a platform, and allows plugins to extend the checks.
Flake8 will run third-party extensions if they are found and installed.
But what does all of that mean?
Anthony Sottile is a maintainer of flake8 and has kindly offered to explain it to us.
Links:
- Flake8: Your Tool For Style Guide Enforcement
- pyflakes
- pycodestyle
- mccabe
- pyflakes/messages.py
- flake8 Error / Violation Codes
- wemake-python-styleguide
- flake8-typing-imports
- tox automation project
- Nox
- pre-commit
By default, it includes lint checks provided Pyflakes, pycodestyle, and McCabe
It's also a platform, and allows plugins to extend the checks.
Flake8 will run third-party extensions if they are found and installed.
But what does all of that mean?
Anthony Sottile is a maintainer of flake8 and has kindly offered to explain it to us.
Links:
- Flake8: Your Tool For Style Guide Enforcement
- pyflakes
- pycodestyle
- mccabe
- pyflakes/messages.py
- flake8 Error / Violation Codes
- wemake-python-styleguide
- flake8-typing-imports
- tox automation project
- Nox
- pre-commit
They are actually awesome questions to ask during a software project.
We discuss the questions, where they came from, and look at some uses in software.
The questions:
- What is it that needs to be done?
- What do we need in order to do it?
- Where can we get what we need?
- How can we tell if we’re doing it right?
Bonus question that can be swapped out for #1:
- What's the most important thing that it doesn't do yet?
Links:
They are actually awesome questions to ask during a software project.
We discuss the questions, where they came from, and look at some uses in software.
The questions:
- What is it that needs to be done?
- What do we need in order to do it?
- Where can we get what we need?
- How can we tell if we’re doing it right?
Bonus question that can be swapped out for #1:
- What's the most important thing that it doesn't do yet?
Links:
They are actually awesome questions to ask during a software project.
We discuss the questions, where they came from, and look at some uses in software.
The questions:
- What is it that needs to be done?
- What do we need in order to do it?
- Where can we get what we need?
- How can we tell if we’re doing it right?
Bonus question that can be swapped out for #1:
- What's the most important thing that it doesn't do yet?
Links:
In this episode, we talk with Jeff about testing web applications, specifically Django apps, and of course talk about the downsides of database mocking.
Links:
- "🤔 In ~12 years, I have never seen a case where mocking a database was a good idea. ..."
- Django News
- Moto
- Test & Code 103: Django - Lacey Williams Henschel
- Model Bakery: Smart fixtures for better tests
- Faker
In this episode, we talk with Jeff about testing web applications, specifically Django apps, and of course talk about the downsides of database mocking.
Links:
- "🤔 In ~12 years, I have never seen a case where mocking a database was a good idea. ..."
- Django News
- Moto
- Test & Code 103: Django - Lacey Williams Henschel
- Model Bakery: Smart fixtures for better tests
- Faker
In this episode, we talk with Jeff about testing web applications, specifically Django apps, and of course talk about the downsides of database mocking.
Links:
- "🤔 In ~12 years, I have never seen a case where mocking a database was a good idea. ..."
- Django News
- Moto
- Test & Code 103: Django - Lacey Williams Henschel
- Model Bakery: Smart fixtures for better tests
- Faker
Links:
Links:
Links:
We talk about the packaging workflow, tools, changes, pyproject.toml, flit, setuptools, and so much more.
I hope you learn as much as I did in this great discussion.
Links:
- pytest-srcpaths
- Python Packaging User Guide
- pypa/packaging: Core utilities for Python packages
- flit and requires-python
- Extending and Embedding the Python Interpreter — Python 3.9.2 documentation
- Flit
- setuptools
- PEP 518 -- Specifying Minimum Build System Requirements for Python Projects | Python.org
- PEP 517 -- A build-system independent format for source trees | Python.org
- Flit editable installs with --symlink or --pth-file
- PEP 440 -- Version Identification and Dependency Specification | Python.org
- Specifying requires-python with flit
- wheel
- Universal 1 binary
- Universal 2 binary
- Cython: C-Extensions for Python
- CFFI
- pybind11: Seamless operability between C++11 and Python
- Conda
- conda environments
- conda-forge
- VaultsOfParnassus
We talk about the packaging workflow, tools, changes, pyproject.toml, flit, setuptools, and so much more.
I hope you learn as much as I did in this great discussion.
Links:
- pytest-srcpaths
- Python Packaging User Guide
- pypa/packaging: Core utilities for Python packages
- flit and requires-python
- Extending and Embedding the Python Interpreter — Python 3.9.2 documentation
- Flit
- setuptools
- PEP 518 -- Specifying Minimum Build System Requirements for Python Projects | Python.org
- PEP 517 -- A build-system independent format for source trees | Python.org
- Flit editable installs with --symlink or --pth-file
- PEP 440 -- Version Identification and Dependency Specification | Python.org
- Specifying requires-python with flit
- wheel
- Universal 1 binary
- Universal 2 binary
- Cython: C-Extensions for Python
- CFFI
- pybind11: Seamless operability between C++11 and Python
- Conda
- conda environments
- conda-forge
- VaultsOfParnassus
We talk about the packaging workflow, tools, changes, pyproject.toml, flit, setuptools, and so much more.
I hope you learn as much as I did in this great discussion.
Links:
- pytest-srcpaths
- Python Packaging User Guide
- pypa/packaging: Core utilities for Python packages
- flit and requires-python
- Extending and Embedding the Python Interpreter — Python 3.9.2 documentation
- Flit
- setuptools
- PEP 518 -- Specifying Minimum Build System Requirements for Python Projects | Python.org
- PEP 517 -- A build-system independent format for source trees | Python.org
- Flit editable installs with --symlink or --pth-file
- PEP 440 -- Version Identification and Dependency Specification | Python.org
- Specifying requires-python with flit
- wheel
- Universal 1 binary
- Universal 2 binary
- Cython: C-Extensions for Python
- CFFI
- pybind11: Seamless operability between C++11 and Python
- Conda
- conda environments
- conda-forge
- VaultsOfParnassus
What's happening is that I'm playing adventure, which you can pip install thanks to Brandon Rohdes. Adventure is a faithful port to Python 3 from the original 1977 FORTRAN code by Crowther and Woods that lets you explore Colossal Cave, where others have found fortunes in treasure and gold, ...
In this episode, we talk with Brandon Rhodes about this marvelous game.
Links:
- adventure · PyPI
- python-adventure: Original Colossal Caves adventure game, but in Python 3
- Brandon Rhodes Personal Site
- Python Design Patterns
- pyephem: Scientific-grade astronomy routines for Python
- python-skyfield: Elegant astronomy for Python
- Adventure in Python 3 - announcement blog post from 2012
- NetHack
- FTL: Faster Than Light
- PEP 517 -- A build-system independent format for source trees | Python.org
What's happening is that I'm playing adventure, which you can pip install thanks to Brandon Rohdes. Adventure is a faithful port to Python 3 from the original 1977 FORTRAN code by Crowther and Woods that lets you explore Colossal Cave, where others have found fortunes in treasure and gold, ...
In this episode, we talk with Brandon Rhodes about this marvelous game.
Links:
- adventure · PyPI
- python-adventure: Original Colossal Caves adventure game, but in Python 3
- Brandon Rhodes Personal Site
- Python Design Patterns
- pyephem: Scientific-grade astronomy routines for Python
- python-skyfield: Elegant astronomy for Python
- Adventure in Python 3 - announcement blog post from 2012
- NetHack
- FTL: Faster Than Light
- PEP 517 -- A build-system independent format for source trees | Python.org
What's happening is that I'm playing adventure, which you can pip install thanks to Brandon Rohdes. Adventure is a faithful port to Python 3 from the original 1977 FORTRAN code by Crowther and Woods that lets you explore Colossal Cave, where others have found fortunes in treasure and gold, ...
In this episode, we talk with Brandon Rhodes about this marvelous game.
Links:
- adventure · PyPI
- python-adventure: Original Colossal Caves adventure game, but in Python 3
- Brandon Rhodes Personal Site
- Python Design Patterns
- pyephem: Scientific-grade astronomy routines for Python
- python-skyfield: Elegant astronomy for Python
- Adventure in Python 3 - announcement blog post from 2012
- NetHack
- FTL: Faster Than Light
- PEP 517 -- A build-system independent format for source trees | Python.org
Reason for the interview. Rough summary of a twitter conversation:
- Corey: What podcasts should I try to get an invite onto?
- ToonArmyCaptain: Python Bytes, Test & Code, Talk Python
- Corey: But... I don't test my code, "crappy Python" is all I write, and I'd feel like a giant imposter. So yeah, I'd be game. link
- So here we are.
This diagram is referenced in the show, the Last Week In AWS Newsletter Production Pipeline.
Special Guest: Corey Quinn.
Links:
Reason for the interview. Rough summary of a twitter conversation:
- Corey: What podcasts should I try to get an invite onto?
- ToonArmyCaptain: Python Bytes, Test & Code, Talk Python
- Corey: But... I don't test my code, "crappy Python" is all I write, and I'd feel like a giant imposter. So yeah, I'd be game. link
- So here we are.
This diagram is referenced in the show, the Last Week In AWS Newsletter Production Pipeline.
Special Guest: Corey Quinn.
Links:
Reason for the interview. Rough summary of a twitter conversation:
- Corey: What podcasts should I try to get an invite onto?
- ToonArmyCaptain: Python Bytes, Test & Code, Talk Python
- Corey: But... I don't test my code, "crappy Python" is all I write, and I'd feel like a giant imposter. So yeah, I'd be game. link
- So here we are.
This diagram is referenced in the show, the Last Week In AWS Newsletter Production Pipeline.
Special Guest: Corey Quinn.
Links:
Also, a couple followups from last week's episode on using coverage for single file applications.
Links:
- episode 147: Testing Single File Python Applications/Scripts with pytest and coverage
- Specifying source files — Coverage.py documentation
- Testing & Packaging - Hynek
- ack
Also, a couple followups from last week's episode on using coverage for single file applications.
Links:
- episode 147: Testing Single File Python Applications/Scripts with pytest and coverage
- Specifying source files — Coverage.py documentation
- Testing & Packaging - Hynek
- ack
Also, a couple followups from last week's episode on using coverage for single file applications.
Links:
- episode 147: Testing Single File Python Applications/Scripts with pytest and coverage
- Specifying source files — Coverage.py documentation
- Testing & Packaging - Hynek
- ack
Have you written tests for it?
Do you check code coverage?
This is the topic of this weeks episode, spurred on by a listener question.
The questions:
- For single file scripts, I'd like to have the test code included right there in the file. Can I do that with pytest?
- If I can, can I use code coverage on it?
The example code discussed in the episode: script.py
def foo(): return 5 def main(): x = foo() print(x) if __name__ == '__main__': # pragma: no cover main() ## test code # To test: # pip install pytest # pytest script.py # To test with coverage: # put this file (script.py) in a directory by itself, say foo # then from the parent directory of foo: # pip install pytest-cov # pytest --cov=foo foo/script.py # To show missing lines # pytest --cov=foo --cov-report=term-missing foo/script.py def test_foo(): assert foo() == 5 def test_main(capsys): main() captured = capsys.readouterr() assert captured.out == "5\n"Suggestion by @cfbolz if you need to import pytest:
if __name__ == '__main__': # pragma: no cover main() else: import pytestHave you written tests for it?
Do you check code coverage?
This is the topic of this weeks episode, spurred on by a listener question.
The questions:
- For single file scripts, I'd like to have the test code included right there in the file. Can I do that with pytest?
- If I can, can I use code coverage on it?
The example code discussed in the episode: script.py
def foo(): return 5 def main(): x = foo() print(x) if __name__ == '__main__': # pragma: no cover main() ## test code # To test: # pip install pytest # pytest script.py # To test with coverage: # put this file (script.py) in a directory by itself, say foo # then from the parent directory of foo: # pip install pytest-cov # pytest --cov=foo foo/script.py # To show missing lines # pytest --cov=foo --cov-report=term-missing foo/script.py def test_foo(): assert foo() == 5 def test_main(capsys): main() captured = capsys.readouterr() assert captured.out == "5\n"Suggestion by @cfbolz if you need to import pytest:
if __name__ == '__main__': # pragma: no cover main() else: import pytestHave you written tests for it?
Do you check code coverage?
This is the topic of this weeks episode, spurred on by a listener question.
The questions:
- For single file scripts, I'd like to have the test code included right there in the file. Can I do that with pytest?
- If I can, can I use code coverage on it?
The example code discussed in the episode: script.py
def foo(): return 5 def main(): x = foo() print(x) if __name__ == '__main__': # pragma: no cover main() ## test code # To test: # pip install pytest # pytest script.py # To test with coverage: # put this file (script.py) in a directory by itself, say foo # then from the parent directory of foo: # pip install pytest-cov # pytest --cov=foo foo/script.py # To show missing lines # pytest --cov=foo --cov-report=term-missing foo/script.py def test_foo(): assert foo() == 5 def test_main(capsys): main() captured = capsys.readouterr() assert captured.out == "5\n"Suggestion by @cfbolz if you need to import pytest:
if __name__ == '__main__': # pragma: no cover main() else: import pytestThere's automated testing, and there's manual testing.
In between that is exploratory testing aided by automation tools.
Michael Kennedy joins the show this week to share some of the tools he uses during development and maintenance.
We talk about tools used for semi-automated exploratory testing.
We also talk about some of the other tools and techniques he uses to keep Talk Python Training, Talk Python, and Python Bytes all up and running smoothly.
We talk about:
- Postman
- ngrok
- sitemap link testing
- scripts for manual processes
- using failover servers during maintenance, redeployments, etc
- gitHub webhooks and scripts to between fail over servers and production during deployments automatically
- floating IP addresses
- services to monitor your site: StatusCake, BetterUptime
- the affect of monitoring on analytics
- crash reporting: Rollbar, Sentry
- response times
- load testing: Locus
Links:
- Python Bytes Podcast
- Talk Python To Me Podcast
- Talk Python Training
- Postman
- ngrok
- StatusCake
- Better Uptime
- Rollbar
- Sentry
- Locust
- 12 requests per second in Python
There's automated testing, and there's manual testing.
In between that is exploratory testing aided by automation tools.
Michael Kennedy joins the show this week to share some of the tools he uses during development and maintenance.
We talk about tools used for semi-automated exploratory testing.
We also talk about some of the other tools and techniques he uses to keep Talk Python Training, Talk Python, and Python Bytes all up and running smoothly.
We talk about:
- Postman
- ngrok
- sitemap link testing
- scripts for manual processes
- using failover servers during maintenance, redeployments, etc
- gitHub webhooks and scripts to between fail over servers and production during deployments automatically
- floating IP addresses
- services to monitor your site: StatusCake, BetterUptime
- the affect of monitoring on analytics
- crash reporting: Rollbar, Sentry
- response times
- load testing: Locus
Links:
- Python Bytes Podcast
- Talk Python To Me Podcast
- Talk Python Training
- Postman
- ngrok
- StatusCake
- Better Uptime
- Rollbar
- Sentry
- Locust
- 12 requests per second in Python
There's automated testing, and there's manual testing.
In between that is exploratory testing aided by automation tools.
Michael Kennedy joins the show this week to share some of the tools he uses during development and maintenance.
We talk about tools used for semi-automated exploratory testing.
We also talk about some of the other tools and techniques he uses to keep Talk Python Training, Talk Python, and Python Bytes all up and running smoothly.
We talk about:
- Postman
- ngrok
- sitemap link testing
- scripts for manual processes
- using failover servers during maintenance, redeployments, etc
- gitHub webhooks and scripts to between fail over servers and production during deployments automatically
- floating IP addresses
- services to monitor your site: StatusCake, BetterUptime
- the affect of monitoring on analytics
- crash reporting: Rollbar, Sentry
- response times
- load testing: Locus
Links:
- Python Bytes Podcast
- Talk Python To Me Podcast
- Talk Python Training
- Postman
- ngrok
- StatusCake
- Better Uptime
- Rollbar
- Sentry
- Locust
- 12 requests per second in Python
Of course we discuss mocking and unittest.mock.
We also discuss:
- testing philosophy
- unit testing and what a unit is
- TDD
- where Michael's towel is, and what color
Micheal was instrumental in the building of testing tools for Python, and continues to be a pragmatic source of honest testing philosopy in a field that has a lot of contradictory information.
Links:
- unittest.mock - Python docs
- Mocks Aren't Stubs - Martin Fowler
- pytest-mock
- mock.patch
- Autospeccing
- Arrange Act Assert
- testing-in-python mailing list
- Classical and Mockist Testing — Classical and Mockist Testing
- Test First Programming / Test First Development
- episode 102: Cosmic Python, TDD, testing and external dependencies - Harry Percival
- episode 132: mocking in Python - Anna-Lena Popkes
- pytest
- unittest - Python docs
- pytest assert usage
- 30 best practices for software development and testing | Opensource.com
Of course we discuss mocking and unittest.mock.
We also discuss:
- testing philosophy
- unit testing and what a unit is
- TDD
- where Michael's towel is, and what color
Micheal was instrumental in the building of testing tools for Python, and continues to be a pragmatic source of honest testing philosopy in a field that has a lot of contradictory information.
Links:
- unittest.mock - Python docs
- Mocks Aren't Stubs - Martin Fowler
- pytest-mock
- mock.patch
- Autospeccing
- Arrange Act Assert
- testing-in-python mailing list
- Classical and Mockist Testing — Classical and Mockist Testing
- Test First Programming / Test First Development
- episode 102: Cosmic Python, TDD, testing and external dependencies - Harry Percival
- episode 132: mocking in Python - Anna-Lena Popkes
- pytest
- unittest - Python docs
- pytest assert usage
- 30 best practices for software development and testing | Opensource.com
Of course we discuss mocking and unittest.mock.
We also discuss:
- testing philosophy
- unit testing and what a unit is
- TDD
- where Michael's towel is, and what color
Micheal was instrumental in the building of testing tools for Python, and continues to be a pragmatic source of honest testing philosopy in a field that has a lot of contradictory information.
Links:
- unittest.mock - Python docs
- Mocks Aren't Stubs - Martin Fowler
- pytest-mock
- mock.patch
- Autospeccing
- Arrange Act Assert
- testing-in-python mailing list
- Classical and Mockist Testing — Classical and Mockist Testing
- Test First Programming / Test First Development
- episode 102: Cosmic Python, TDD, testing and external dependencies - Harry Percival
- episode 132: mocking in Python - Anna-Lena Popkes
- pytest
- unittest - Python docs
- pytest assert usage
- 30 best practices for software development and testing | Opensource.com
Martin and Brian discuss TDD and testing and Martin's experience with testing, TDD, and using it for code involved with scientific research.
We discuss lots of topics around this, including:
- What is TDD?
- Should research software be tested in order to be trusted?
- Time pressure and the struggle to get code done quickly. How do you make time for tests also?
- Is testing worth it for code that will not be reused?
- Sometimes it's hard to know how to test something.
- Maybe people should learn to test alongside learning how to code.
- A desire for a resource of testing concepts for non-CS people.
- Are the testing needs and testing information needs different in different disciplines?
- Biology, Physics, Astrophysics, etc. Do they have different testing needs?
- Do we need a "how to test" resource for each?
Special Guest: Martin Héroux.
Links:
- Joy Division Album Cover
- episode 140: Testing in Scientific Research and Academia - Martin Héroux — Martin's previous episode.
Martin and Brian discuss TDD and testing and Martin's experience with testing, TDD, and using it for code involved with scientific research.
We discuss lots of topics around this, including:
- What is TDD?
- Should research software be tested in order to be trusted?
- Time pressure and the struggle to get code done quickly. How do you make time for tests also?
- Is testing worth it for code that will not be reused?
- Sometimes it's hard to know how to test something.
- Maybe people should learn to test alongside learning how to code.
- A desire for a resource of testing concepts for non-CS people.
- Are the testing needs and testing information needs different in different disciplines?
- Biology, Physics, Astrophysics, etc. Do they have different testing needs?
- Do we need a "how to test" resource for each?
Special Guest: Martin Héroux.
Links:
- Joy Division Album Cover
- episode 140: Testing in Scientific Research and Academia - Martin Héroux — Martin's previous episode.
Martin and Brian discuss TDD and testing and Martin's experience with testing, TDD, and using it for code involved with scientific research.
We discuss lots of topics around this, including:
- What is TDD?
- Should research software be tested in order to be trusted?
- Time pressure and the struggle to get code done quickly. How do you make time for tests also?
- Is testing worth it for code that will not be reused?
- Sometimes it's hard to know how to test something.
- Maybe people should learn to test alongside learning how to code.
- A desire for a resource of testing concepts for non-CS people.
- Are the testing needs and testing information needs different in different disciplines?
- Biology, Physics, Astrophysics, etc. Do they have different testing needs?
- Do we need a "how to test" resource for each?
Special Guest: Martin Héroux.
Links:
- Joy Division Album Cover
- episode 140: Testing in Scientific Research and Academia - Martin Héroux — Martin's previous episode.
Some of what we talk about:
- Running a subset of tests with markers.
- Using marker expressions with and, or, not, and parentheses.
- Keyword expressions also can use and, or, not, and parentheses.
- Markers and pytest functionality that use mark, such as parametrize, skipif, etc.
- Accessing markers with itermarkers and get_closest_marker through item.
- Passing values, metadata through markers to fixtures or hook functions.
Links:
- Registering markers
- slow marker example in pytest documentation — Control skipping of tests according to command line option
- pytest-repeat · PyPI
- source code for pytest-repeat
- Working with custom markers — pytest documentation
- Using -k expr to select tests based on their name
- Marker revamp and iteration, Historical Notes — pytest documentation
Some of what we talk about:
- Running a subset of tests with markers.
- Using marker expressions with and, or, not, and parentheses.
- Keyword expressions also can use and, or, not, and parentheses.
- Markers and pytest functionality that use mark, such as parametrize, skipif, etc.
- Accessing markers with itermarkers and get_closest_marker through item.
- Passing values, metadata through markers to fixtures or hook functions.
Links:
- Registering markers
- slow marker example in pytest documentation — Control skipping of tests according to command line option
- pytest-repeat · PyPI
- source code for pytest-repeat
- Working with custom markers — pytest documentation
- Using -k expr to select tests based on their name
- Marker revamp and iteration, Historical Notes — pytest documentation
Some of what we talk about:
- Running a subset of tests with markers.
- Using marker expressions with and, or, not, and parentheses.
- Keyword expressions also can use and, or, not, and parentheses.
- Markers and pytest functionality that use mark, such as parametrize, skipif, etc.
- Accessing markers with itermarkers and get_closest_marker through item.
- Passing values, metadata through markers to fixtures or hook functions.
Links:
- Registering markers
- slow marker example in pytest documentation — Control skipping of tests according to command line option
- pytest-repeat · PyPI
- source code for pytest-repeat
- Working with custom markers — pytest documentation
- Using -k expr to select tests based on their name
- Marker revamp and iteration, Historical Notes — pytest documentation
Mark Smith, a developer advocate for MongoDB, answers my many questions about MongoDB.
We cover some basics, but also discuss some advanced features that I never knew about before this conversation.
Special Guest: Mark Smith.
Links:
- MongoDB
- Everything You Know About MongoDB is Wrong!
- Implementing Event Sourcing and CQRS pattern with MongoDB
Mark Smith, a developer advocate for MongoDB, answers my many questions about MongoDB.
We cover some basics, but also discuss some advanced features that I never knew about before this conversation.
Special Guest: Mark Smith.
Links:
- MongoDB
- Everything You Know About MongoDB is Wrong!
- Implementing Event Sourcing and CQRS pattern with MongoDB
Mark Smith, a developer advocate for MongoDB, answers my many questions about MongoDB.
We cover some basics, but also discuss some advanced features that I never knew about before this conversation.
Special Guest: Mark Smith.
Links:
- MongoDB
- Everything You Know About MongoDB is Wrong!
- Implementing Event Sourcing and CQRS pattern with MongoDB
Some of the discussion:
- Classes of visual testing:
- problems with pixel to pixel testing
- DOM comparisons, css, html, etc.
- AI driven picture level testing, where failures look into the DOM to help describe the problem.
- Where visual testing fits into a test strategy.
- Combining "does this look right" visual testing with other test workflows.
- "A picture is worth a thousand assertions" - functional assertions built into visual testing.
- Baselining pictures in the test workflow.
Also discussed:
- automation engineer
- Test Automation University
Links:
Some of the discussion:
- Classes of visual testing:
- problems with pixel to pixel testing
- DOM comparisons, css, html, etc.
- AI driven picture level testing, where failures look into the DOM to help describe the problem.
- Where visual testing fits into a test strategy.
- Combining "does this look right" visual testing with other test workflows.
- "A picture is worth a thousand assertions" - functional assertions built into visual testing.
- Baselining pictures in the test workflow.
Also discussed:
- automation engineer
- Test Automation University
Links:
Some of the discussion:
- Classes of visual testing:
- problems with pixel to pixel testing
- DOM comparisons, css, html, etc.
- AI driven picture level testing, where failures look into the DOM to help describe the problem.
- Where visual testing fits into a test strategy.
- Combining "does this look right" visual testing with other test workflows.
- "A picture is worth a thousand assertions" - functional assertions built into visual testing.
- Baselining pictures in the test workflow.
Also discussed:
- automation engineer
- Test Automation University
Links:
Some of them learn it in college, but even if they do, that's not their focus.
It's not surprising that sharing the software used for scientific research and papers is spotty, at best.
And what about testing?
We'd hope that the software behind scientific research is tested.
But why would we expect that?
We're lucky if CS students get a class or two that even mentions automated tests.
Why would we expect other scientists to just know how to test their code?
Martin works in research and this discussion is about software and testing in scientific research and academia.
Special Guest: Martin Héroux.
Links:
- Python Testing with pytest: Simple, Rapid, Effective, and Scalable
- Test Driven Development: By Example
- My reaction to "Is TDD Dead?" - Python Testing
- MartinHeroux/pliffy: Plotting differences with Python
- PyBites Code Challenges
- Python Morsels
- Martin Héroux (@martin_heroux) / Twitter
- Scientifically Sound
- Martin Héroux - Google Scholar
- spike2py · PyPI
- pytest-mpl · PyPI
Some of them learn it in college, but even if they do, that's not their focus.
It's not surprising that sharing the software used for scientific research and papers is spotty, at best.
And what about testing?
We'd hope that the software behind scientific research is tested.
But why would we expect that?
We're lucky if CS students get a class or two that even mentions automated tests.
Why would we expect other scientists to just know how to test their code?
Martin works in research and this discussion is about software and testing in scientific research and academia.
Special Guest: Martin Héroux.
Links:
- Python Testing with pytest: Simple, Rapid, Effective, and Scalable
- Test Driven Development: By Example
- My reaction to "Is TDD Dead?" - Python Testing
- MartinHeroux/pliffy: Plotting differences with Python
- PyBites Code Challenges
- Python Morsels
- Martin Héroux (@martin_heroux) / Twitter
- Scientifically Sound
- Martin Héroux - Google Scholar
- spike2py · PyPI
- pytest-mpl · PyPI
Some of them learn it in college, but even if they do, that's not their focus.
It's not surprising that sharing the software used for scientific research and papers is spotty, at best.
And what about testing?
We'd hope that the software behind scientific research is tested.
But why would we expect that?
We're lucky if CS students get a class or two that even mentions automated tests.
Why would we expect other scientists to just know how to test their code?
Martin works in research and this discussion is about software and testing in scientific research and academia.
Special Guest: Martin Héroux.
Links:
- Python Testing with pytest: Simple, Rapid, Effective, and Scalable
- Test Driven Development: By Example
- My reaction to "Is TDD Dead?" - Python Testing
- MartinHeroux/pliffy: Plotting differences with Python
- PyBites Code Challenges
- Python Morsels
- Martin Héroux (@martin_heroux) / Twitter
- Scientifically Sound
- Martin Héroux - Google Scholar
- spike2py · PyPI
- pytest-mpl · PyPI
We talk a software development and "shift left" where automated tests and quality checks have moved earlier into the software lifecycle.
- Software approaches and where quality fits in
- Shift left
- Test automation
- Roles of software developers, SDETs (software development engineer in test), testers, QA, etc.
- Developers doing testing and devops
- Automated testing vs manual testing
- Regression testing, UI testing, black bock testing
- Unit testing, white box, API, end to end testing
- User acceptance testing (UAT)
- Mullet Methodology (Agile at the front, Waterfall at the back)
- Waterwheel Methodology (Requirements -> iterative development -> QA)
- What's an agile team?
- Developer resistance to testing
- Manifesto for agile software development
- Iterative development
- Adapting to change
- Agility: being able to change course quickly
Special Guests: Nalin Parbhu and Ola Omiyale.
We talk a software development and "shift left" where automated tests and quality checks have moved earlier into the software lifecycle.
- Software approaches and where quality fits in
- Shift left
- Test automation
- Roles of software developers, SDETs (software development engineer in test), testers, QA, etc.
- Developers doing testing and devops
- Automated testing vs manual testing
- Regression testing, UI testing, black bock testing
- Unit testing, white box, API, end to end testing
- User acceptance testing (UAT)
- Mullet Methodology (Agile at the front, Waterfall at the back)
- Waterwheel Methodology (Requirements -> iterative development -> QA)
- What's an agile team?
- Developer resistance to testing
- Manifesto for agile software development
- Iterative development
- Adapting to change
- Agility: being able to change course quickly
Special Guests: Nalin Parbhu and Ola Omiyale.
We talk a software development and "shift left" where automated tests and quality checks have moved earlier into the software lifecycle.
- Software approaches and where quality fits in
- Shift left
- Test automation
- Roles of software developers, SDETs (software development engineer in test), testers, QA, etc.
- Developers doing testing and devops
- Automated testing vs manual testing
- Regression testing, UI testing, black bock testing
- Unit testing, white box, API, end to end testing
- User acceptance testing (UAT)
- Mullet Methodology (Agile at the front, Waterfall at the back)
- Waterwheel Methodology (Requirements -> iterative development -> QA)
- What's an agile team?
- Developer resistance to testing
- Manifesto for agile software development
- Iterative development
- Adapting to change
- Agility: being able to change course quickly
Special Guests: Nalin Parbhu and Ola Omiyale.
Mutation testing is a way to tell you about the quality of your test suite.
Anders Hovmöller wrote mutmut for mutation testing in Python, and can be used with pytest, unittest, and others.
In this episode, Anders explains mutation testing, how mutation testing with mutmut works, and good workflows.
Special Guest: Anders Hovmöller.
Links:
- mutmut · PyPI
- cosmic-ray · PyPI
- MutPy · PyPI
- parso · PyPI
- mutmut documentation
- Ned Batchelder article on mutmut
Mutation testing is a way to tell you about the quality of your test suite.
Anders Hovmöller wrote mutmut for mutation testing in Python, and can be used with pytest, unittest, and others.
In this episode, Anders explains mutation testing, how mutation testing with mutmut works, and good workflows.
Special Guest: Anders Hovmöller.
Links:
- mutmut · PyPI
- cosmic-ray · PyPI
- MutPy · PyPI
- parso · PyPI
- mutmut documentation
- Ned Batchelder article on mutmut
Mutation testing is a way to tell you about the quality of your test suite.
Anders Hovmöller wrote mutmut for mutation testing in Python, and can be used with pytest, unittest, and others.
In this episode, Anders explains mutation testing, how mutation testing with mutmut works, and good workflows.
Special Guest: Anders Hovmöller.
Links:
- mutmut · PyPI
- cosmic-ray · PyPI
- MutPy · PyPI
- parso · PyPI
- mutmut documentation
- Ned Batchelder article on mutmut
As part of this course, he's including interviews with people who have already written books, including me. This is that interview.
We discuss:
- Why I wrote "Python Testing with pytest"
- Self publishing vs working with a publisher
- The writing, editing, and publishing process
- Writing format
- Book promotion
- Advice to other writers
Special Guest: Matt Harrison.
Links:
- Effective Book Authoring — Matt's course
- Python Testing with pytest - Simple, Rapid, Effective, and Scalable
As part of this course, he's including interviews with people who have already written books, including me. This is that interview.
We discuss:
- Why I wrote "Python Testing with pytest"
- Self publishing vs working with a publisher
- The writing, editing, and publishing process
- Writing format
- Book promotion
- Advice to other writers
Special Guest: Matt Harrison.
Links:
- Effective Book Authoring — Matt's course
- Python Testing with pytest - Simple, Rapid, Effective, and Scalable
As part of this course, he's including interviews with people who have already written books, including me. This is that interview.
We discuss:
- Why I wrote "Python Testing with pytest"
- Self publishing vs working with a publisher
- The writing, editing, and publishing process
- Writing format
- Book promotion
- Advice to other writers
Special Guest: Matt Harrison.
Links:
- Effective Book Authoring — Matt's course
- Python Testing with pytest - Simple, Rapid, Effective, and Scalable
Wearable tech also includes one off projects by designers, makers, and hackers and there are more and more people producing tutorials on how to get started. Wearable tech is also a great way to get both kids and adults excited about coding, electronics, and in general, engineering skills.
Sophy Wong is a designer who makes really cool stuff using code, technology, costuming, soldering, and even jewelry techniques to get tech onto the human body.
Sophy joins the show to answer my many questions about getting started safely with wearable tech.
Some of the questions and topics:
- Can I wash my clothing if I've added tech to it?
- Is there any danger in wearing technology or building wearable tech?
- Are there actual wires and cables conductive thread in the fabric and textiles of some wearable tech projects?
- What's a good starter project? Especially if I want to do a wearable tech project with my kids?
- Dealing with stretch with clothing and non-bendy electronics.
- Some questions around the Sophy Wong and HackSpace "Wearable Tech Projects" book.
- How did you get into wearable tech?
- Do you have a favorite project?
- Can I get into wearable tech if I don't know how to code or solder?
- Are these projects accessible to people with limited budgets?
- Making projects so you can reuse the expensive bits on multiple projects.
Special Guest: Sophy Wong.
Links:
- sophywong.com
- Wearable Tech Projects book — The wearable technology book
- costumes — The dress is on this page, as well as the Ghostbuster pack and costume.
- spacesuit
- Music video with Sophy's space suit
- Kobakant tutorials
Wearable tech also includes one off projects by designers, makers, and hackers and there are more and more people producing tutorials on how to get started. Wearable tech is also a great way to get both kids and adults excited about coding, electronics, and in general, engineering skills.
Sophy Wong is a designer who makes really cool stuff using code, technology, costuming, soldering, and even jewelry techniques to get tech onto the human body.
Sophy joins the show to answer my many questions about getting started safely with wearable tech.
Some of the questions and topics:
- Can I wash my clothing if I've added tech to it?
- Is there any danger in wearing technology or building wearable tech?
- Are there actual wires and cables conductive thread in the fabric and textiles of some wearable tech projects?
- What's a good starter project? Especially if I want to do a wearable tech project with my kids?
- Dealing with stretch with clothing and non-bendy electronics.
- Some questions around the Sophy Wong and HackSpace "Wearable Tech Projects" book.
- How did you get into wearable tech?
- Do you have a favorite project?
- Can I get into wearable tech if I don't know how to code or solder?
- Are these projects accessible to people with limited budgets?
- Making projects so you can reuse the expensive bits on multiple projects.
Special Guest: Sophy Wong.
Links:
- sophywong.com
- Wearable Tech Projects book — The wearable technology book
- costumes — The dress is on this page, as well as the Ghostbuster pack and costume.
- spacesuit
- Music video with Sophy's space suit
- Kobakant tutorials
Wearable tech also includes one off projects by designers, makers, and hackers and there are more and more people producing tutorials on how to get started. Wearable tech is also a great way to get both kids and adults excited about coding, electronics, and in general, engineering skills.
Sophy Wong is a designer who makes really cool stuff using code, technology, costuming, soldering, and even jewelry techniques to get tech onto the human body.
Sophy joins the show to answer my many questions about getting started safely with wearable tech.
Some of the questions and topics:
- Can I wash my clothing if I've added tech to it?
- Is there any danger in wearing technology or building wearable tech?
- Are there actual wires and cables conductive thread in the fabric and textiles of some wearable tech projects?
- What's a good starter project? Especially if I want to do a wearable tech project with my kids?
- Dealing with stretch with clothing and non-bendy electronics.
- Some questions around the Sophy Wong and HackSpace "Wearable Tech Projects" book.
- How did you get into wearable tech?
- Do you have a favorite project?
- Can I get into wearable tech if I don't know how to code or solder?
- Are these projects accessible to people with limited budgets?
- Making projects so you can reuse the expensive bits on multiple projects.
Special Guest: Sophy Wong.
Links:
- sophywong.com
- Wearable Tech Projects book — The wearable technology book
- costumes — The dress is on this page, as well as the Ghostbuster pack and costume.
- spacesuit
- Music video with Sophy's space suit
- Kobakant tutorials
What can you do about it to keep test suites fast?
Some things, like parallelization, are applicable to many domains.
What about, for instance, Django applications?
Well, Adam Johnson has thought about it a lot, and is here to tell us how we can speed up our Django test suites.
Topics include:
- parallelizing tests
- moving from disk to memory
- using fake data and factory functions
- targeted mocking
Special Guest: Adam Johnson.
Links:
- Speed Up Your Django Tests — the book by Adam Johnson
- Kukicha — "or twig tea, ..., is a Japanese blend made of stems, stalks, and twigs."
What can you do about it to keep test suites fast?
Some things, like parallelization, are applicable to many domains.
What about, for instance, Django applications?
Well, Adam Johnson has thought about it a lot, and is here to tell us how we can speed up our Django test suites.
Topics include:
- parallelizing tests
- moving from disk to memory
- using fake data and factory functions
- targeted mocking
Special Guest: Adam Johnson.
Links:
- Speed Up Your Django Tests — the book by Adam Johnson
- Kukicha — "or twig tea, ..., is a Japanese blend made of stems, stalks, and twigs."
What can you do about it to keep test suites fast?
Some things, like parallelization, are applicable to many domains.
What about, for instance, Django applications?
Well, Adam Johnson has thought about it a lot, and is here to tell us how we can speed up our Django test suites.
Topics include:
- parallelizing tests
- moving from disk to memory
- using fake data and factory functions
- targeted mocking
Special Guest: Adam Johnson.
Links:
- Speed Up Your Django Tests — the book by Adam Johnson
- Kukicha — "or twig tea, ..., is a Japanese blend made of stems, stalks, and twigs."
We talk about:
- Business outcomes vs vanity metrics
- As a developer, how do you keep business outcomes in mind
- Thinking about customer value all the time
- Communicating decisions and options in terms of costs and impact on business outcomes
- Company culture and it's role in reinforcing a business outcome mindset
- And even the role of team lead as impact multiplier
I really enjoyed this conversation. But I admit that at first, I didn't realize how important this is on all software development. Metrics are front and center in a web app. But what about a service, or an embedded system with no telemetry. It still matters, maybe even more so. Little and big decisions developers face every day that have impact on costs and benefits with respect to customer value and business outcome, even if it's difficult to measure.
Special Guest: Benjamin Harding.
We talk about:
- Business outcomes vs vanity metrics
- As a developer, how do you keep business outcomes in mind
- Thinking about customer value all the time
- Communicating decisions and options in terms of costs and impact on business outcomes
- Company culture and it's role in reinforcing a business outcome mindset
- And even the role of team lead as impact multiplier
I really enjoyed this conversation. But I admit that at first, I didn't realize how important this is on all software development. Metrics are front and center in a web app. But what about a service, or an embedded system with no telemetry. It still matters, maybe even more so. Little and big decisions developers face every day that have impact on costs and benefits with respect to customer value and business outcome, even if it's difficult to measure.
Special Guest: Benjamin Harding.
We talk about:
- Business outcomes vs vanity metrics
- As a developer, how do you keep business outcomes in mind
- Thinking about customer value all the time
- Communicating decisions and options in terms of costs and impact on business outcomes
- Company culture and it's role in reinforcing a business outcome mindset
- And even the role of team lead as impact multiplier
I really enjoyed this conversation. But I admit that at first, I didn't realize how important this is on all software development. Metrics are front and center in a web app. But what about a service, or an embedded system with no telemetry. It still matters, maybe even more so. Little and big decisions developers face every day that have impact on costs and benefits with respect to customer value and business outcome, even if it's difficult to measure.
Special Guest: Benjamin Harding.
Hacking can be thought of as tinkering. Taking things apart and putting them back together as an interesting experience. There's always been some of this as part of software culture.
The people at Major League Hacking have taken this to a whole new level, bringing together Tech creators who enjoy playing around with and crating new technology, on campuses, and now in virtual spaces, all over the world.
Jonathon Gottfried, one of the cofounders of Major League Hacking, joins the show to talk about:
- hacker meetups and events
- hackathons
- what it's like to go to a hackathon
- how to help out with hackathons as an experienced engineer, even virtually as a mentor
- hackathons continuing virtually during the pandemic
- internships and fellowships on open source projects to help students gain experience, even during the pandemic
- MLH approach to internships, giving interns a support group, including peers, mentors, and project maintainers
- and MLH itself
Special Guest: Jon Gottfried.
Links:
Hacking can be thought of as tinkering. Taking things apart and putting them back together as an interesting experience. There's always been some of this as part of software culture.
The people at Major League Hacking have taken this to a whole new level, bringing together Tech creators who enjoy playing around with and crating new technology, on campuses, and now in virtual spaces, all over the world.
Jonathon Gottfried, one of the cofounders of Major League Hacking, joins the show to talk about:
- hacker meetups and events
- hackathons
- what it's like to go to a hackathon
- how to help out with hackathons as an experienced engineer, even virtually as a mentor
- hackathons continuing virtually during the pandemic
- internships and fellowships on open source projects to help students gain experience, even during the pandemic
- MLH approach to internships, giving interns a support group, including peers, mentors, and project maintainers
- and MLH itself
Special Guest: Jon Gottfried.
Links:
Hacking can be thought of as tinkering. Taking things apart and putting them back together as an interesting experience. There's always been some of this as part of software culture.
The people at Major League Hacking have taken this to a whole new level, bringing together Tech creators who enjoy playing around with and crating new technology, on campuses, and now in virtual spaces, all over the world.
Jonathon Gottfried, one of the cofounders of Major League Hacking, joins the show to talk about:
- hacker meetups and events
- hackathons
- what it's like to go to a hackathon
- how to help out with hackathons as an experienced engineer, even virtually as a mentor
- hackathons continuing virtually during the pandemic
- internships and fellowships on open source projects to help students gain experience, even during the pandemic
- MLH approach to internships, giving interns a support group, including peers, mentors, and project maintainers
- and MLH itself
Special Guest: Jon Gottfried.
Links:
Anna-Lena joins the podcast to teach us about mocks and using unittest.mock objects during testing.
We discuss:
- the different styles of using mocks
- pros and cons of mocks
- dependency injection
- adapter pattern
- mock hell
- magical universe
- and much more
Special Guest: Anna-Lena Popkes.
Links:
- Personal webpage of Anna-Lena Popkes
- Magical Universe — Awesome Python features explained using the world of magic
- Test & Code 102: Cosmic Python, TDD, testing and external dependencies — The episode where Harry Percival discusses mocking.
- Talk: Harry Percival - Stop Using Mocks (for a while) - YouTube — Talk: Harry Percival - Stop Using Mocks (for a while)
- unittest.mock
- Autospeccing
- Mock Hell Talk (45 min version) Edwin Jung - PyCon 2019
- Mock Hell Talk (30 min version) - Edwin Jung - PyConDE
- PyCon Estonia
- KI macht Schule!
- Talk Python #186 : 100 Days of Python in a Magical Universe
Anna-Lena joins the podcast to teach us about mocks and using unittest.mock objects during testing.
We discuss:
- the different styles of using mocks
- pros and cons of mocks
- dependency injection
- adapter pattern
- mock hell
- magical universe
- and much more
Special Guest: Anna-Lena Popkes.
Links:
- Personal webpage of Anna-Lena Popkes
- Magical Universe — Awesome Python features explained using the world of magic
- Test & Code 102: Cosmic Python, TDD, testing and external dependencies — The episode where Harry Percival discusses mocking.
- Talk: Harry Percival - Stop Using Mocks (for a while) - YouTube — Talk: Harry Percival - Stop Using Mocks (for a while)
- unittest.mock
- Autospeccing
- Mock Hell Talk (45 min version) Edwin Jung - PyCon 2019
- Mock Hell Talk (30 min version) - Edwin Jung - PyConDE
- PyCon Estonia
- KI macht Schule!
- Talk Python #186 : 100 Days of Python in a Magical Universe
Anna-Lena joins the podcast to teach us about mocks and using unittest.mock objects during testing.
We discuss:
- the different styles of using mocks
- pros and cons of mocks
- dependency injection
- adapter pattern
- mock hell
- magical universe
- and much more
Special Guest: Anna-Lena Popkes.
Links:
- Personal webpage of Anna-Lena Popkes
- Magical Universe — Awesome Python features explained using the world of magic
- Test & Code 102: Cosmic Python, TDD, testing and external dependencies — The episode where Harry Percival discusses mocking.
- Talk: Harry Percival - Stop Using Mocks (for a while) - YouTube — Talk: Harry Percival - Stop Using Mocks (for a while)
- unittest.mock
- Autospeccing
- Mock Hell Talk (45 min version) Edwin Jung - PyCon 2019
- Mock Hell Talk (30 min version) - Edwin Jung - PyConDE
- PyCon Estonia
- KI macht Schule!
- Talk Python #186 : 100 Days of Python in a Magical Universe
There is a better way.
In this episode, I'm going to share some advice from Luke Plant on how to "Test Smarter, Not Harder".
Links:
- Test smarter, not harder - lukeplant.me.uk — The original article by Luke
There is a better way.
In this episode, I'm going to share some advice from Luke Plant on how to "Test Smarter, Not Harder".
Links:
- Test smarter, not harder - lukeplant.me.uk — The original article by Luke
There is a better way.
In this episode, I'm going to share some advice from Luke Plant on how to "Test Smarter, Not Harder".
Links:
- Test smarter, not harder - lukeplant.me.uk — The original article by Luke
Brian Skinn initially noticed that on Windows cmd, a space was added between a prefix defined by --prompt and the rest of the prompt, whereas on bash no space was added.
For reference, there were/are three nominal virtualenv prompt modification behaviors, all of which apply to the prompt changes that are made at the time of virtualenv activation:
- If the environment variable VIRTUAL_ENV_DISABLE_PROMPT is defined and non-empty at activation time, do not modify the prompt at all. Otherwise:
- If the --prompt argument was supplied at creation time, use that argument as the prefix to apply to the prompt; or,
- If the --prompt argument was not supplied at creation time, use the default prefix of "() " as the prefix (the environment folder name surrounded by parentheses, and with a trailing space after the last paren.
Special Guest: Brian Skinn.
Links:
- virtualenv
- Initial issue that started the adventure
- final PR
- pent: pent Extracts Numerical Text -- Mini-language driven parser for structured numerical data
- Lightening talk on pent
Brian Skinn initially noticed that on Windows cmd, a space was added between a prefix defined by --prompt and the rest of the prompt, whereas on bash no space was added.
For reference, there were/are three nominal virtualenv prompt modification behaviors, all of which apply to the prompt changes that are made at the time of virtualenv activation:
- If the environment variable VIRTUAL_ENV_DISABLE_PROMPT is defined and non-empty at activation time, do not modify the prompt at all. Otherwise:
- If the --prompt argument was supplied at creation time, use that argument as the prefix to apply to the prompt; or,
- If the --prompt argument was not supplied at creation time, use the default prefix of "() " as the prefix (the environment folder name surrounded by parentheses, and with a trailing space after the last paren.
Special Guest: Brian Skinn.
Links:
- virtualenv
- Initial issue that started the adventure
- final PR
- pent: pent Extracts Numerical Text -- Mini-language driven parser for structured numerical data
- Lightening talk on pent
Brian Skinn initially noticed that on Windows cmd, a space was added between a prefix defined by --prompt and the rest of the prompt, whereas on bash no space was added.
For reference, there were/are three nominal virtualenv prompt modification behaviors, all of which apply to the prompt changes that are made at the time of virtualenv activation:
- If the environment variable VIRTUAL_ENV_DISABLE_PROMPT is defined and non-empty at activation time, do not modify the prompt at all. Otherwise:
- If the --prompt argument was supplied at creation time, use that argument as the prefix to apply to the prompt; or,
- If the --prompt argument was not supplied at creation time, use the default prefix of "() " as the prefix (the environment folder name surrounded by parentheses, and with a trailing space after the last paren.
Special Guest: Brian Skinn.
Links:
- virtualenv
- Initial issue that started the adventure
- final PR
- pent: pent Extracts Numerical Text -- Mini-language driven parser for structured numerical data
- Lightening talk on pent
Lots of responses. David Lord agreed to answer them with me.
In the process, we come up with lots of great general advice on how to test just about anything.
Specific Questions people asked:
- What makes a good test?
- How do you test web app performance?
- How do you test cookie cutter templates?
- How do I test my test framework?
- How do I test permission management?
- How do I test SQLAlchemy models and pydantic schemas in a FastAPI app?
- How do I test warehouse ETL code?
- How do I test and mock GPIO pins on hardware for code running MicroPython on a device?
- How do I test PyQt apps?
- How do I test web scrapers?
- Is it the best practice to put static html in your test directory or just snippets stored in string variables?
- What's the best way to to test server client API contracts?
- How do I test a monitoring tool?
We also talk about:
- What is the Flask testing philosophy?
- What do Flask tests look like?
- Flask and Pallets using pytest
- Code coverage
Some of the resulting testing strategies:
- Set up some preconditions. Run the function. Get the result.
- Don't test external services.
- Do test external service failures.
- Don't test the frameworks you are using.
- Do test your use of a framework.
- Use open source projects to learn how something similar to your project tests things.
- Focus on your code.
- Focus on testing your new code.
- Try to architect your application such that actual GUI testing is minimal.
- Split up a large problem into smaller parts that are easier to test.
- Nail down as many parts as you can.
Special Guest: David Lord.
Lots of responses. David Lord agreed to answer them with me.
In the process, we come up with lots of great general advice on how to test just about anything.
Specific Questions people asked:
- What makes a good test?
- How do you test web app performance?
- How do you test cookie cutter templates?
- How do I test my test framework?
- How do I test permission management?
- How do I test SQLAlchemy models and pydantic schemas in a FastAPI app?
- How do I test warehouse ETL code?
- How do I test and mock GPIO pins on hardware for code running MicroPython on a device?
- How do I test PyQt apps?
- How do I test web scrapers?
- Is it the best practice to put static html in your test directory or just snippets stored in string variables?
- What's the best way to to test server client API contracts?
- How do I test a monitoring tool?
We also talk about:
- What is the Flask testing philosophy?
- What do Flask tests look like?
- Flask and Pallets using pytest
- Code coverage
Some of the resulting testing strategies:
- Set up some preconditions. Run the function. Get the result.
- Don't test external services.
- Do test external service failures.
- Don't test the frameworks you are using.
- Do test your use of a framework.
- Use open source projects to learn how something similar to your project tests things.
- Focus on your code.
- Focus on testing your new code.
- Try to architect your application such that actual GUI testing is minimal.
- Split up a large problem into smaller parts that are easier to test.
- Nail down as many parts as you can.
Special Guest: David Lord.
Lots of responses. David Lord agreed to answer them with me.
In the process, we come up with lots of great general advice on how to test just about anything.
Specific Questions people asked:
- What makes a good test?
- How do you test web app performance?
- How do you test cookie cutter templates?
- How do I test my test framework?
- How do I test permission management?
- How do I test SQLAlchemy models and pydantic schemas in a FastAPI app?
- How do I test warehouse ETL code?
- How do I test and mock GPIO pins on hardware for code running MicroPython on a device?
- How do I test PyQt apps?
- How do I test web scrapers?
- Is it the best practice to put static html in your test directory or just snippets stored in string variables?
- What's the best way to to test server client API contracts?
- How do I test a monitoring tool?
We also talk about:
- What is the Flask testing philosophy?
- What do Flask tests look like?
- Flask and Pallets using pytest
- Code coverage
Some of the resulting testing strategies:
- Set up some preconditions. Run the function. Get the result.
- Don't test external services.
- Do test external service failures.
- Don't test the frameworks you are using.
- Do test your use of a framework.
- Use open source projects to learn how something similar to your project tests things.
- Focus on your code.
- Focus on testing your new code.
- Try to architect your application such that actual GUI testing is minimal.
- Split up a large problem into smaller parts that are easier to test.
- Nail down as many parts as you can.
Special Guest: David Lord.
However, system state often gets in the way and order dependence can creep into a test suite.
One way to fight against order dependence is to randomize test order, and with pytest, we recommend the plugin pytest-randomly to do that for you.
The developer that started pytest-randomly and continues to support it is Adam Johnson, who joins us today to discuss pytest-randomly and another plugin he also wrote, called pytest-reverse.
Special Guest: Adam Johnson.
Links:
- pytest-randomly: pytest plugin to randomly order tests and control random.seed
- pytest-reverse: pytest plugin to reverse test order.
- Empirically revisiting the test independence assumption
- pytest-xdist
- factory_boy
- Faker
- NumPy
- Hyrum's Law
However, system state often gets in the way and order dependence can creep into a test suite.
One way to fight against order dependence is to randomize test order, and with pytest, we recommend the plugin pytest-randomly to do that for you.
The developer that started pytest-randomly and continues to support it is Adam Johnson, who joins us today to discuss pytest-randomly and another plugin he also wrote, called pytest-reverse.
Special Guest: Adam Johnson.
Links:
- pytest-randomly: pytest plugin to randomly order tests and control random.seed
- pytest-reverse: pytest plugin to reverse test order.
- Empirically revisiting the test independence assumption
- pytest-xdist
- factory_boy
- Faker
- NumPy
- Hyrum's Law
However, system state often gets in the way and order dependence can creep into a test suite.
One way to fight against order dependence is to randomize test order, and with pytest, we recommend the plugin pytest-randomly to do that for you.
The developer that started pytest-randomly and continues to support it is Adam Johnson, who joins us today to discuss pytest-randomly and another plugin he also wrote, called pytest-reverse.
Special Guest: Adam Johnson.
Links:
- pytest-randomly: pytest plugin to randomly order tests and control random.seed
- pytest-reverse: pytest plugin to reverse test order.
- Empirically revisiting the test independence assumption
- pytest-xdist
- factory_boy
- Faker
- NumPy
- Hyrum's Law
Or at least are working from home more than they ever did before. That's definitely true for me.
Even though I've been working from home since March, I wanted some tips from people who have been doing it longer.
Julian Sequeira, of PyBites fame, has been working from home for about a year.
Reuven Lerner, an amazing Python trainer, has been working from home for much longer.
We originally had a big list of WFH topics. But we had so much fun with the tips and tricks part, that that's pretty much the whole episode.
But there's lots of great tips and tricks, so I'm glad we focused on that.
Special Guests: Julian Sequeira and Reuven Lerner.
Links:
- PyBites — Julian's site for teaching Python
- Teaching Python and data science around the world — Reuven Lerner
- Bonbon - Wikipedia
- Test & Code Mailing List — Join for your chance to win a free course from Talk Python Training. One course given away every week for 6 weeks.
Or at least are working from home more than they ever did before. That's definitely true for me.
Even though I've been working from home since March, I wanted some tips from people who have been doing it longer.
Julian Sequeira, of PyBites fame, has been working from home for about a year.
Reuven Lerner, an amazing Python trainer, has been working from home for much longer.
We originally had a big list of WFH topics. But we had so much fun with the tips and tricks part, that that's pretty much the whole episode.
But there's lots of great tips and tricks, so I'm glad we focused on that.
Special Guests: Julian Sequeira and Reuven Lerner.
Links:
- PyBites — Julian's site for teaching Python
- Teaching Python and data science around the world — Reuven Lerner
- Bonbon - Wikipedia
- Test & Code Mailing List — Join for your chance to win a free course from Talk Python Training. One course given away every week for 6 weeks.
Or at least are working from home more than they ever did before. That's definitely true for me.
Even though I've been working from home since March, I wanted some tips from people who have been doing it longer.
Julian Sequeira, of PyBites fame, has been working from home for about a year.
Reuven Lerner, an amazing Python trainer, has been working from home for much longer.
We originally had a big list of WFH topics. But we had so much fun with the tips and tricks part, that that's pretty much the whole episode.
But there's lots of great tips and tricks, so I'm glad we focused on that.
Special Guests: Julian Sequeira and Reuven Lerner.
Links:
- PyBites — Julian's site for teaching Python
- Teaching Python and data science around the world — Reuven Lerner
- Bonbon - Wikipedia
- Test & Code Mailing List — Join for your chance to win a free course from Talk Python Training. One course given away every week for 6 weeks.
Joel joins the show this week to talk about data science, software engineering, and even Fizz Buzz.
Topics include:
- Software Engineering practices and data science
- Difficulties with Jupyter notebooks
- Code reviews on experiment code
- Unit tests on experiment code
- Finding bugs before doing experiments
- Tests for data pipelines
- Tests for deep learning models
- Showing researchers the value of tests by showing the bugs found that wouldn't have been found without them.
- "Data Science from Scratch" book
- Showing testing during teaching Data Science
- "Ten Essays on Fizz Buzz" book
- Meditations on Python, mathematics, science, engineerign and design
- Testing Fizz Buzz
- Different algorithms and solutions to an age old interview question.
- If not Fizz Buzz, what makes a decent coding interview question.
- pytest
- hypothesis
- Math requirements for data science
Special Guest: Joel Grus.
Links:
Joel joins the show this week to talk about data science, software engineering, and even Fizz Buzz.
Topics include:
- Software Engineering practices and data science
- Difficulties with Jupyter notebooks
- Code reviews on experiment code
- Unit tests on experiment code
- Finding bugs before doing experiments
- Tests for data pipelines
- Tests for deep learning models
- Showing researchers the value of tests by showing the bugs found that wouldn't have been found without them.
- "Data Science from Scratch" book
- Showing testing during teaching Data Science
- "Ten Essays on Fizz Buzz" book
- Meditations on Python, mathematics, science, engineerign and design
- Testing Fizz Buzz
- Different algorithms and solutions to an age old interview question.
- If not Fizz Buzz, what makes a decent coding interview question.
- pytest
- hypothesis
- Math requirements for data science
Special Guest: Joel Grus.
Links:
Joel joins the show this week to talk about data science, software engineering, and even Fizz Buzz.
Topics include:
- Software Engineering practices and data science
- Difficulties with Jupyter notebooks
- Code reviews on experiment code
- Unit tests on experiment code
- Finding bugs before doing experiments
- Tests for data pipelines
- Tests for deep learning models
- Showing researchers the value of tests by showing the bugs found that wouldn't have been found without them.
- "Data Science from Scratch" book
- Showing testing during teaching Data Science
- "Ten Essays on Fizz Buzz" book
- Meditations on Python, mathematics, science, engineerign and design
- Testing Fizz Buzz
- Different algorithms and solutions to an age old interview question.
- If not Fizz Buzz, what makes a decent coding interview question.
- pytest
- hypothesis
- Math requirements for data science
Special Guest: Joel Grus.
Links:
And there's lots to be excited about.
Anthony Sottile joins the show to discuss features, improvements, documentation updates and more.
Full release notes / changelog
Some of what we talk about:
- How to update (at least, how I do it)
- Run your test suites with 5.4.3 or whatever the last version you were using
- Update to 6
- Run again. Same output? Probably good.
- If there are any warnings, maybe fix those.
- You can also run with pytest -W error to turn warnings into errors.
- Then find out all the cool stuff you can do now
- New Features
- pytest now supports pyproject.toml files for configuration.
- but remember, toml syntax is different than ini files. mostly quotes are needed
- pytest now includes inline type annotations and exposes them to user programs.
- Most of the user-facing API is covered, as well as internal code.
- New command-line flags --no-header and --no-summary
- A warning is now shown when an unknown key is read from a config INI file.
- The --strict-config flag has been added to treat these warnings as errors.
- New required_plugins configuration option allows the user to specify a list of plugins, including version information, that are required for pytest to run. An error is raised if any required plugins are not found when running pytest.
- pytest now supports pyproject.toml files for configuration.
- Improvements
- You can now pass output to things like less and head that close the pipe passed to them.
- thank you!!!
- Improved precision of test durations measurement.
- use --durations=10 -vv to capture and show durations
- Rich comparison for dataclasses and attrs-classes is now recursive.
- pytest --version now displays just the pytest version,
- while pytest --version --version displays more verbose information including plugins.
- --junitxml now includes the exception cause in the message XML attribute for failures during setup and teardown.
- You can now pass output to things like less and head that close the pipe passed to them.
- Improved Documentation
- Add a note about --strict and --strict-markers and the preference for the latter one.
- Explain indirect parametrization and markers for fixtures.
- Bug Fixes
- Deprecations
- Trivial/Internal Changes
- Breaking Changes you might need to care about before upgrading
- PytestDeprecationWarning are now errors by default.
- Check the deprecations and removals page if you are curious.
- -k and -m internals were rewritten to stop using eval(), this results in a few slight changes but overall makes them much more consistent
- testdir.run().parseoutcomes() now always returns the parsed nouns in plural form.
- I'd say that's an improvement
- PytestDeprecationWarning are now errors by default.
Special Guest: Anthony Sottile.
Links:
And there's lots to be excited about.
Anthony Sottile joins the show to discuss features, improvements, documentation updates and more.
Full release notes / changelog
Some of what we talk about:
- How to update (at least, how I do it)
- Run your test suites with 5.4.3 or whatever the last version you were using
- Update to 6
- Run again. Same output? Probably good.
- If there are any warnings, maybe fix those.
- You can also run with pytest -W error to turn warnings into errors.
- Then find out all the cool stuff you can do now
- New Features
- pytest now supports pyproject.toml files for configuration.
- but remember, toml syntax is different than ini files. mostly quotes are needed
- pytest now includes inline type annotations and exposes them to user programs.
- Most of the user-facing API is covered, as well as internal code.
- New command-line flags --no-header and --no-summary
- A warning is now shown when an unknown key is read from a config INI file.
- The --strict-config flag has been added to treat these warnings as errors.
- New required_plugins configuration option allows the user to specify a list of plugins, including version information, that are required for pytest to run. An error is raised if any required plugins are not found when running pytest.
- pytest now supports pyproject.toml files for configuration.
- Improvements
- You can now pass output to things like less and head that close the pipe passed to them.
- thank you!!!
- Improved precision of test durations measurement.
- use --durations=10 -vv to capture and show durations
- Rich comparison for dataclasses and attrs-classes is now recursive.
- pytest --version now displays just the pytest version,
- while pytest --version --version displays more verbose information including plugins.
- --junitxml now includes the exception cause in the message XML attribute for failures during setup and teardown.
- You can now pass output to things like less and head that close the pipe passed to them.
- Improved Documentation
- Add a note about --strict and --strict-markers and the preference for the latter one.
- Explain indirect parametrization and markers for fixtures.
- Bug Fixes
- Deprecations
- Trivial/Internal Changes
- Breaking Changes you might need to care about before upgrading
- PytestDeprecationWarning are now errors by default.
- Check the deprecations and removals page if you are curious.
- -k and -m internals were rewritten to stop using eval(), this results in a few slight changes but overall makes them much more consistent
- testdir.run().parseoutcomes() now always returns the parsed nouns in plural form.
- I'd say that's an improvement
- PytestDeprecationWarning are now errors by default.
Special Guest: Anthony Sottile.
Links:
And there's lots to be excited about.
Anthony Sottile joins the show to discuss features, improvements, documentation updates and more.
Full release notes / changelog
Some of what we talk about:
- How to update (at least, how I do it)
- Run your test suites with 5.4.3 or whatever the last version you were using
- Update to 6
- Run again. Same output? Probably good.
- If there are any warnings, maybe fix those.
- You can also run with pytest -W error to turn warnings into errors.
- Then find out all the cool stuff you can do now
- New Features
- pytest now supports pyproject.toml files for configuration.
- but remember, toml syntax is different than ini files. mostly quotes are needed
- pytest now includes inline type annotations and exposes them to user programs.
- Most of the user-facing API is covered, as well as internal code.
- New command-line flags --no-header and --no-summary
- A warning is now shown when an unknown key is read from a config INI file.
- The --strict-config flag has been added to treat these warnings as errors.
- New required_plugins configuration option allows the user to specify a list of plugins, including version information, that are required for pytest to run. An error is raised if any required plugins are not found when running pytest.
- pytest now supports pyproject.toml files for configuration.
- Improvements
- You can now pass output to things like less and head that close the pipe passed to them.
- thank you!!!
- Improved precision of test durations measurement.
- use --durations=10 -vv to capture and show durations
- Rich comparison for dataclasses and attrs-classes is now recursive.
- pytest --version now displays just the pytest version,
- while pytest --version --version displays more verbose information including plugins.
- --junitxml now includes the exception cause in the message XML attribute for failures during setup and teardown.
- You can now pass output to things like less and head that close the pipe passed to them.
- Improved Documentation
- Add a note about --strict and --strict-markers and the preference for the latter one.
- Explain indirect parametrization and markers for fixtures.
- Bug Fixes
- Deprecations
- Trivial/Internal Changes
- Breaking Changes you might need to care about before upgrading
- PytestDeprecationWarning are now errors by default.
- Check the deprecations and removals page if you are curious.
- -k and -m internals were rewritten to stop using eval(), this results in a few slight changes but overall makes them much more consistent
- testdir.run().parseoutcomes() now always returns the parsed nouns in plural form.
- I'd say that's an improvement
- PytestDeprecationWarning are now errors by default.
Special Guest: Anthony Sottile.
Links:
Often, when you run pip, especially the first time in a new virtual environment, you will see something like:
WARNING: You are using pip version 20.1.1; however, version 20.2 is available.You should consider upgrading via the 'python -m pip install --upgrade pip' command.
And you should. Because 20.2 has a new dependency resolver.
Get in the habit, until October, of replacing pip install with pip install --use-feature=2020-resolver.
This flag is new in the 20.2 release.
This new pip dependency resolver is the result of a lot of work.
Five of the people involved with this work are joining the show today: Bernard Tyers, Nicole Harris, Paul Moore, Pradyun Gedam, and Tzu-ping Chung.
We talk about:
- pip dependency resolver changes
- user experience research and testing
- crafting good error messages
- efforts to improve the test suite
- testing pip with pytest
- some of the difficulties with testing pip
- working with a team on a large project
- working with a large code base
- bringing new developers into a large project
Special Guests: Bernard Tyers, Nicole Harris, Paul Moore, Pradyun Gedam, and Tzu-ping Chung.
Links:
- Changelog — pip 20.2 documentation — Including --use-feature=2020-resolver
- pypa/pip: The Python package installer — github repo
- testing pip - documentation
- pip - The Python Package Installer — pip 20.2 documentation
- Changes to the pip dependency resolver in 20.2 — Changes to the pip dependency resolver in 20.2
Often, when you run pip, especially the first time in a new virtual environment, you will see something like:
WARNING: You are using pip version 20.1.1; however, version 20.2 is available.You should consider upgrading via the 'python -m pip install --upgrade pip' command.
And you should. Because 20.2 has a new dependency resolver.
Get in the habit, until October, of replacing pip install with pip install --use-feature=2020-resolver.
This flag is new in the 20.2 release.
This new pip dependency resolver is the result of a lot of work.
Five of the people involved with this work are joining the show today: Bernard Tyers, Nicole Harris, Paul Moore, Pradyun Gedam, and Tzu-ping Chung.
We talk about:
- pip dependency resolver changes
- user experience research and testing
- crafting good error messages
- efforts to improve the test suite
- testing pip with pytest
- some of the difficulties with testing pip
- working with a team on a large project
- working with a large code base
- bringing new developers into a large project
Special Guests: Bernard Tyers, Nicole Harris, Paul Moore, Pradyun Gedam, and Tzu-ping Chung.
Links:
- Changelog — pip 20.2 documentation — Including --use-feature=2020-resolver
- pypa/pip: The Python package installer — github repo
- testing pip - documentation
- pip - The Python Package Installer — pip 20.2 documentation
- Changes to the pip dependency resolver in 20.2 — Changes to the pip dependency resolver in 20.2
Often, when you run pip, especially the first time in a new virtual environment, you will see something like:
WARNING: You are using pip version 20.1.1; however, version 20.2 is available.You should consider upgrading via the 'python -m pip install --upgrade pip' command.
And you should. Because 20.2 has a new dependency resolver.
Get in the habit, until October, of replacing pip install with pip install --use-feature=2020-resolver.
This flag is new in the 20.2 release.
This new pip dependency resolver is the result of a lot of work.
Five of the people involved with this work are joining the show today: Bernard Tyers, Nicole Harris, Paul Moore, Pradyun Gedam, and Tzu-ping Chung.
We talk about:
- pip dependency resolver changes
- user experience research and testing
- crafting good error messages
- efforts to improve the test suite
- testing pip with pytest
- some of the difficulties with testing pip
- working with a team on a large project
- working with a large code base
- bringing new developers into a large project
Special Guests: Bernard Tyers, Nicole Harris, Paul Moore, Pradyun Gedam, and Tzu-ping Chung.
Links:
- Changelog — pip 20.2 documentation — Including --use-feature=2020-resolver
- pypa/pip: The Python package installer — github repo
- testing pip - documentation
- pip - The Python Package Installer — pip 20.2 documentation
- Changes to the pip dependency resolver in 20.2 — Changes to the pip dependency resolver in 20.2
Tania Allard, a Senior Cloud Developer Advocate at Microsoft, joins the show to answer some of my questions regarding setting up a Python project to use Actions.
Some of the topics covered:
- How to get started with GitHub Actions for a Python project?
- What are workflow files?
- Does it matter what the file name is called?
- Can I have / Should I have more than one workflow?
Special Guest: Tania Allard.
Links:
- Using Python with GitHub Actions - GitHub Docs
- awesome-actions — A curated list of awesome actions to use on GitHub
Tania Allard, a Senior Cloud Developer Advocate at Microsoft, joins the show to answer some of my questions regarding setting up a Python project to use Actions.
Some of the topics covered:
- How to get started with GitHub Actions for a Python project?
- What are workflow files?
- Does it matter what the file name is called?
- Can I have / Should I have more than one workflow?
Special Guest: Tania Allard.
Links:
- Using Python with GitHub Actions - GitHub Docs
- awesome-actions — A curated list of awesome actions to use on GitHub
Tania Allard, a Senior Cloud Developer Advocate at Microsoft, joins the show to answer some of my questions regarding setting up a Python project to use Actions.
Some of the topics covered:
- How to get started with GitHub Actions for a Python project?
- What are workflow files?
- Does it matter what the file name is called?
- Can I have / Should I have more than one workflow?
Special Guest: Tania Allard.
Links:
- Using Python with GitHub Actions - GitHub Docs
- awesome-actions — A curated list of awesome actions to use on GitHub
There's no surprise there.
But so many people make mistakes on their resume that can very easily be fixed.
Randall Kanna is on the show today to help us understand how to improve our resumes, and in turn, help us have better careers.
Special Guest: Randall Kanna.
Links:
- The Standout Developer — link includes discount
There's no surprise there.
But so many people make mistakes on their resume that can very easily be fixed.
Randall Kanna is on the show today to help us understand how to improve our resumes, and in turn, help us have better careers.
Special Guest: Randall Kanna.
Links:
- The Standout Developer — link includes discount
There's no surprise there.
But so many people make mistakes on their resume that can very easily be fixed.
Randall Kanna is on the show today to help us understand how to improve our resumes, and in turn, help us have better careers.
Special Guest: Randall Kanna.
Links:
- The Standout Developer — link includes discount
there's a bunch of Python in those printers as well.
In this episode we talk about:
- 3D printers
- What are the different types of 3D printers?
- Where are 3D printed industrial parts being used?
- Why use one type of additive manufacturing over another?
- Python in 3D printing hardware.
- What are Finite State Machines, FSMs?
- Benefits of FSMs for testing, logging, and breaking a complex behavior into small testable parts.
- Benefits of simulation in writing and testing software to control hardware.
Special Guest: Len Wanger.
Links:
- pystate — Python package for co-routine base state machines
- Impossible Objects — Composite 3D Printing
- Finite-state machine, FSM
there's a bunch of Python in those printers as well.
In this episode we talk about:
- 3D printers
- What are the different types of 3D printers?
- Where are 3D printed industrial parts being used?
- Why use one type of additive manufacturing over another?
- Python in 3D printing hardware.
- What are Finite State Machines, FSMs?
- Benefits of FSMs for testing, logging, and breaking a complex behavior into small testable parts.
- Benefits of simulation in writing and testing software to control hardware.
Special Guest: Len Wanger.
Links:
- pystate — Python package for co-routine base state machines
- Impossible Objects — Composite 3D Printing
- Finite-state machine, FSM
there's a bunch of Python in those printers as well.
In this episode we talk about:
- 3D printers
- What are the different types of 3D printers?
- Where are 3D printed industrial parts being used?
- Why use one type of additive manufacturing over another?
- Python in 3D printing hardware.
- What are Finite State Machines, FSMs?
- Benefits of FSMs for testing, logging, and breaking a complex behavior into small testable parts.
- Benefits of simulation in writing and testing software to control hardware.
Special Guest: Len Wanger.
Links:
- pystate — Python package for co-routine base state machines
- Impossible Objects — Composite 3D Printing
- Finite-state machine, FSM
Typer is a library for building CLI applications, also based on Python type hints.
Type hints and many other details are intended to make it easier to develop, test, and debug applications using FastAPI and Typer.
The person behind FastAPI and Typer is Sebastián Ramírez.
Sebastián is on the show today, and we discuss:
- FastAPI
- Rest APIs
- Swagger UI
- Future features of FastAPI
- Starlette
- Typer
- Click
- Testing with Typer and Click
- Typer autocompletion
- Typer CLI
Special Guest: Sebastián Ramírez.
Links:
- Explosion
- FastAPI
- Typer
- OpenAPI Specification
- JSON Schema
- OAuth 2.0
- Starlette
- pydantic
- Swagger UI — REST API Documentation Tool
- Testing - Typer
- Click
- Testing Click Applications
- CLI Option autocompletion - Typer
- Typer CLI - completion for small scripts
Typer is a library for building CLI applications, also based on Python type hints.
Type hints and many other details are intended to make it easier to develop, test, and debug applications using FastAPI and Typer.
The person behind FastAPI and Typer is Sebastián Ramírez.
Sebastián is on the show today, and we discuss:
- FastAPI
- Rest APIs
- Swagger UI
- Future features of FastAPI
- Starlette
- Typer
- Click
- Testing with Typer and Click
- Typer autocompletion
- Typer CLI
Special Guest: Sebastián Ramírez.
Links:
- Explosion
- FastAPI
- Typer
- OpenAPI Specification
- JSON Schema
- OAuth 2.0
- Starlette
- pydantic
- Swagger UI — REST API Documentation Tool
- Testing - Typer
- Click
- Testing Click Applications
- CLI Option autocompletion - Typer
- Typer CLI - completion for small scripts
Typer is a library for building CLI applications, also based on Python type hints.
Type hints and many other details are intended to make it easier to develop, test, and debug applications using FastAPI and Typer.
The person behind FastAPI and Typer is Sebastián Ramírez.
Sebastián is on the show today, and we discuss:
- FastAPI
- Rest APIs
- Swagger UI
- Future features of FastAPI
- Starlette
- Typer
- Click
- Testing with Typer and Click
- Typer autocompletion
- Typer CLI
Special Guest: Sebastián Ramírez.
Links:
- Explosion
- FastAPI
- Typer
- OpenAPI Specification
- JSON Schema
- OAuth 2.0
- Starlette
- pydantic
- Swagger UI — REST API Documentation Tool
- Testing - Typer
- Click
- Testing Click Applications
- CLI Option autocompletion - Typer
- Typer CLI - completion for small scripts
Brett and I talk about some upcoming work on Python packaging, such as:
- editable installs
- the need for standardization
- configuration of other tools in pyproject.toml
And then get off on tangents and talk about:
- why it's good to have packages like pip, toml, setuptools, wheel, etc not part of the standard library
- should we remove some stuff from the standard library
- the standard library using unittest for testing the standard library
- why not hypothesis
- I didn't bring up "why not pytest?" but you know I was thinking it.
- why CPython and not C++Python
- and more
Special Guest: Brett Cannon.
Links:
- episode 52: pyproject.toml : the future of Python packaging - Brett Cannon
- Python Packaging Authority
- PEP 517 -- A build-system independent format for source trees
- PEP 518 -- Specifying Minimum Build System Requirements for Python Projects
- What the heck is pyproject.toml?
- Flit
- Poetry
- enscons
- toml
- setuptools
- distutils
- pip
- HTTPX
Brett and I talk about some upcoming work on Python packaging, such as:
- editable installs
- the need for standardization
- configuration of other tools in pyproject.toml
And then get off on tangents and talk about:
- why it's good to have packages like pip, toml, setuptools, wheel, etc not part of the standard library
- should we remove some stuff from the standard library
- the standard library using unittest for testing the standard library
- why not hypothesis
- I didn't bring up "why not pytest?" but you know I was thinking it.
- why CPython and not C++Python
- and more
Special Guest: Brett Cannon.
Links:
- episode 52: pyproject.toml : the future of Python packaging - Brett Cannon
- Python Packaging Authority
- PEP 517 -- A build-system independent format for source trees
- PEP 518 -- Specifying Minimum Build System Requirements for Python Projects
- What the heck is pyproject.toml?
- Flit
- Poetry
- enscons
- toml
- setuptools
- distutils
- pip
- HTTPX
Brett and I talk about some upcoming work on Python packaging, such as:
- editable installs
- the need for standardization
- configuration of other tools in pyproject.toml
And then get off on tangents and talk about:
- why it's good to have packages like pip, toml, setuptools, wheel, etc not part of the standard library
- should we remove some stuff from the standard library
- the standard library using unittest for testing the standard library
- why not hypothesis
- I didn't bring up "why not pytest?" but you know I was thinking it.
- why CPython and not C++Python
- and more
Special Guest: Brett Cannon.
Links:
- episode 52: pyproject.toml : the future of Python packaging - Brett Cannon
- Python Packaging Authority
- PEP 517 -- A build-system independent format for source trees
- PEP 518 -- Specifying Minimum Build System Requirements for Python Projects
- What the heck is pyproject.toml?
- Flit
- Poetry
- enscons
- toml
- setuptools
- distutils
- pip
- HTTPX
Coverage tools are an important part of software engineering.
But there's also lots of different opinions about using it.
- Should you try for 100% coverage?
- What code can and should you exclude?
- What about targets?
I've been asked many times what I think about code coverage or test coverage.
This episode is a train of thought brain dump on what I think about code coverage.
We'll talk about:
- how I use code coverage to help me write source code
- line coverage and branch coverage
- behavior coverage
- using tests to ask and answer questions about the system under test
- how to target coverage just to the code you care about
- excluding code
- good reasons and bad reasons to exclude code
And also the Pareto Principle or 80/20 rule, and the law of diminishing returns and how that applies (or doesn't) to test coverage.
Links:
Coverage tools are an important part of software engineering.
But there's also lots of different opinions about using it.
- Should you try for 100% coverage?
- What code can and should you exclude?
- What about targets?
I've been asked many times what I think about code coverage or test coverage.
This episode is a train of thought brain dump on what I think about code coverage.
We'll talk about:
- how I use code coverage to help me write source code
- line coverage and branch coverage
- behavior coverage
- using tests to ask and answer questions about the system under test
- how to target coverage just to the code you care about
- excluding code
- good reasons and bad reasons to exclude code
And also the Pareto Principle or 80/20 rule, and the law of diminishing returns and how that applies (or doesn't) to test coverage.
Links:
Coverage tools are an important part of software engineering.
But there's also lots of different opinions about using it.
- Should you try for 100% coverage?
- What code can and should you exclude?
- What about targets?
I've been asked many times what I think about code coverage or test coverage.
This episode is a train of thought brain dump on what I think about code coverage.
We'll talk about:
- how I use code coverage to help me write source code
- line coverage and branch coverage
- behavior coverage
- using tests to ask and answer questions about the system under test
- how to target coverage just to the code you care about
- excluding code
- good reasons and bad reasons to exclude code
And also the Pareto Principle or 80/20 rule, and the law of diminishing returns and how that applies (or doesn't) to test coverage.
Links:
Brett Cannon is the manager for the distributed development team of the Python extension for VS Code.
In this episode, Brett and I discuss the Python extension and VS Code, including:
- pytest support
- virtual environment support
- how settings work, including user and workspace settings
- multi root projects
- testing Python in VS Code
- debugging and pydevd
- jump to cursor feature
- upcoming features
Special Guest: Brett Cannon.
Links:
- Brett Cannon on Changelog
- John Wick
- Ballerina
- Frank Willison Award
- Python extension for VS Code
- episode 117 : How IDEs can make software testing easier - Paul Everitt
- User and Workspace Settings
- virtual environments
- Testing Python in VS Code
- pydevd
- Jump to Cursor in Feb VS Code Python blog
Brett Cannon is the manager for the distributed development team of the Python extension for VS Code.
In this episode, Brett and I discuss the Python extension and VS Code, including:
- pytest support
- virtual environment support
- how settings work, including user and workspace settings
- multi root projects
- testing Python in VS Code
- debugging and pydevd
- jump to cursor feature
- upcoming features
Special Guest: Brett Cannon.
Links:
- Brett Cannon on Changelog
- John Wick
- Ballerina
- Frank Willison Award
- Python extension for VS Code
- episode 117 : How IDEs can make software testing easier - Paul Everitt
- User and Workspace Settings
- virtual environments
- Testing Python in VS Code
- pydevd
- Jump to Cursor in Feb VS Code Python blog
Brett Cannon is the manager for the distributed development team of the Python extension for VS Code.
In this episode, Brett and I discuss the Python extension and VS Code, including:
- pytest support
- virtual environment support
- how settings work, including user and workspace settings
- multi root projects
- testing Python in VS Code
- debugging and pydevd
- jump to cursor feature
- upcoming features
Special Guest: Brett Cannon.
Links:
- Brett Cannon on Changelog
- John Wick
- Ballerina
- Frank Willison Award
- Python extension for VS Code
- episode 117 : How IDEs can make software testing easier - Paul Everitt
- User and Workspace Settings
- virtual environments
- Testing Python in VS Code
- pydevd
- Jump to Cursor in Feb VS Code Python blog
We also discuss fixtures and plugins and other testing tools that work great with pytest
- tox
- GitHub Actions
- Coverage.py
- Selenium + splinter with pytest-splinter
- Hypothesis
And then our list of pytest plugins:
- pytest-sugar
- pytest-cov
- pytest-stress
- pytest-repeat
- pytest-instafail
- pytest-metadata
- pytest-randomly
- pytest-xdist
- pytest-flake8
- pytest-timeout
- pytest-spec
- pytest-picked
- pytest-freezegun
- pytest-check
- fluentcheck
That last one isn't a plugin, but we also talked about pytest-splinter at the beginning. So I think it still counts as 15.
Special Guest: Michael Kennedy.
Links:
- pytest-sugar — changes the default look and feel of pyptest (e.g. progressbar, show tests that fail instantly)
- pytest-cov — run coverage.py from pytest
- pytest-stress — allows you to loop tests for a user defined amount of time.
- pytest-repeat — for repeating test execution
- pytest-instafail — shows failures and errors instantly instead of waiting until the end of test session.
- pytest-metadata — for accessing test session metadata
- pytest-randomly — randomly order tests and control random.seed
- pytest-xdist — distributed testing
- pytest-flake8 — pytest plugin to run flake8
- pytest-timeout — terminate tests after a certain timeout
- pytest-spec — display test execution output like a specification
- pytest-picked — run the tests related to the changed files (according to Git)
- pytest-freezegun — easily freeze time
- pytest-check — allows multiple failures per test
- fluentcheck — fluent assertions
- episode 104 — Top 28 pytest plugins with Anthony Sottile
- Python Testing with pytest — The easiest way to get up to speed with pytest fast. There's also a chapter dedicated to plugins that also teaches you how to write and test your own plugins.
- tox
- GitHub Actions
- Coverage.py
- pytest-splinter — provides a set of fixtures to use splinter for browser testing
- splinter — makes it easy to write automated tests of web applications
- hypothesis — property-based testing
- Talk Python Episode #267 — This episode is a cross post with Talk Python
We also discuss fixtures and plugins and other testing tools that work great with pytest
- tox
- GitHub Actions
- Coverage.py
- Selenium + splinter with pytest-splinter
- Hypothesis
And then our list of pytest plugins:
- pytest-sugar
- pytest-cov
- pytest-stress
- pytest-repeat
- pytest-instafail
- pytest-metadata
- pytest-randomly
- pytest-xdist
- pytest-flake8
- pytest-timeout
- pytest-spec
- pytest-picked
- pytest-freezegun
- pytest-check
- fluentcheck
That last one isn't a plugin, but we also talked about pytest-splinter at the beginning. So I think it still counts as 15.
Special Guest: Michael Kennedy.
Links:
- pytest-sugar — changes the default look and feel of pyptest (e.g. progressbar, show tests that fail instantly)
- pytest-cov — run coverage.py from pytest
- pytest-stress — allows you to loop tests for a user defined amount of time.
- pytest-repeat — for repeating test execution
- pytest-instafail — shows failures and errors instantly instead of waiting until the end of test session.
- pytest-metadata — for accessing test session metadata
- pytest-randomly — randomly order tests and control random.seed
- pytest-xdist — distributed testing
- pytest-flake8 — pytest plugin to run flake8
- pytest-timeout — terminate tests after a certain timeout
- pytest-spec — display test execution output like a specification
- pytest-picked — run the tests related to the changed files (according to Git)
- pytest-freezegun — easily freeze time
- pytest-check — allows multiple failures per test
- fluentcheck — fluent assertions
- episode 104 — Top 28 pytest plugins with Anthony Sottile
- Python Testing with pytest — The easiest way to get up to speed with pytest fast. There's also a chapter dedicated to plugins that also teaches you how to write and test your own plugins.
- tox
- GitHub Actions
- Coverage.py
- pytest-splinter — provides a set of fixtures to use splinter for browser testing
- splinter — makes it easy to write automated tests of web applications
- hypothesis — property-based testing
- Talk Python Episode #267 — This episode is a cross post with Talk Python
We also discuss fixtures and plugins and other testing tools that work great with pytest
- tox
- GitHub Actions
- Coverage.py
- Selenium + splinter with pytest-splinter
- Hypothesis
And then our list of pytest plugins:
- pytest-sugar
- pytest-cov
- pytest-stress
- pytest-repeat
- pytest-instafail
- pytest-metadata
- pytest-randomly
- pytest-xdist
- pytest-flake8
- pytest-timeout
- pytest-spec
- pytest-picked
- pytest-freezegun
- pytest-check
- fluentcheck
That last one isn't a plugin, but we also talked about pytest-splinter at the beginning. So I think it still counts as 15.
Special Guest: Michael Kennedy.
Links:
- pytest-sugar — changes the default look and feel of pyptest (e.g. progressbar, show tests that fail instantly)
- pytest-cov — run coverage.py from pytest
- pytest-stress — allows you to loop tests for a user defined amount of time.
- pytest-repeat — for repeating test execution
- pytest-instafail — shows failures and errors instantly instead of waiting until the end of test session.
- pytest-metadata — for accessing test session metadata
- pytest-randomly — randomly order tests and control random.seed
- pytest-xdist — distributed testing
- pytest-flake8 — pytest plugin to run flake8
- pytest-timeout — terminate tests after a certain timeout
- pytest-spec — display test execution output like a specification
- pytest-picked — run the tests related to the changed files (according to Git)
- pytest-freezegun — easily freeze time
- pytest-check — allows multiple failures per test
- fluentcheck — fluent assertions
- episode 104 — Top 28 pytest plugins with Anthony Sottile
- Python Testing with pytest — The easiest way to get up to speed with pytest fast. There's also a chapter dedicated to plugins that also teaches you how to write and test your own plugins.
- tox
- GitHub Actions
- Coverage.py
- pytest-splinter — provides a set of fixtures to use splinter for browser testing
- splinter — makes it easy to write automated tests of web applications
- hypothesis — property-based testing
- Talk Python Episode #267 — This episode is a cross post with Talk Python
Nina is starting something like the hallway track, online, on twitch, and it's already going, so check out the first episode of Python Tea.
Interesting coincidence is that this episode is kind of like a hallway track discussion between Nina and Brian.
We've had Nina on the show a couple times before, but it's been a while.
In 2018, we talked about Mentoring on episode 44.
In 2019, we talked about giving Memorable Tech Talks in episode 71.
In this episode, we catch up with Nina, find out what she's doing, and talk about a bunch of stuff, including:
- Live Coding
- Online Conferences
- Microsoft Python team
- Python Tea, an online hallway track
- Q&A with Python for VS Code team
- Python on hardware
- Adafruit
- Device Simulator Express
- CircuitPython
- Tricking out your command prompt
- Zsh and Oh My Zsh
- Emacs vs vi key bindings for shells
- Working from home
Special Guest: Nina Zakharenko.
Links:
- nnjaio - Twitch
- Nina Zakharenko 💜🐍 (@nnja) / Twitter
- Device Simulator Express - Visual Studio Marketplace
- Initial code for Microsoft's PyBadge at PyCon 2020
- Goodbye Print, Hello Debugger! - Nina Zakharenko - PyCon 2020 Talk
- 𝙽𝚒𝚗𝚊 𝚉𝚊𝚔𝚑𝚊𝚛𝚎𝚗𝚔𝚘 💜🐍 - DEV.to
- Python Tea Announcement
- The Live Coders Conference
Nina is starting something like the hallway track, online, on twitch, and it's already going, so check out the first episode of Python Tea.
Interesting coincidence is that this episode is kind of like a hallway track discussion between Nina and Brian.
We've had Nina on the show a couple times before, but it's been a while.
In 2018, we talked about Mentoring on episode 44.
In 2019, we talked about giving Memorable Tech Talks in episode 71.
In this episode, we catch up with Nina, find out what she's doing, and talk about a bunch of stuff, including:
- Live Coding
- Online Conferences
- Microsoft Python team
- Python Tea, an online hallway track
- Q&A with Python for VS Code team
- Python on hardware
- Adafruit
- Device Simulator Express
- CircuitPython
- Tricking out your command prompt
- Zsh and Oh My Zsh
- Emacs vs vi key bindings for shells
- Working from home
Special Guest: Nina Zakharenko.
Links:
- nnjaio - Twitch
- Nina Zakharenko 💜🐍 (@nnja) / Twitter
- Device Simulator Express - Visual Studio Marketplace
- Initial code for Microsoft's PyBadge at PyCon 2020
- Goodbye Print, Hello Debugger! - Nina Zakharenko - PyCon 2020 Talk
- 𝙽𝚒𝚗𝚊 𝚉𝚊𝚔𝚑𝚊𝚛𝚎𝚗𝚔𝚘 💜🐍 - DEV.to
- Python Tea Announcement
- The Live Coders Conference
Nina is starting something like the hallway track, online, on twitch, and it's already going, so check out the first episode of Python Tea.
Interesting coincidence is that this episode is kind of like a hallway track discussion between Nina and Brian.
We've had Nina on the show a couple times before, but it's been a while.
In 2018, we talked about Mentoring on episode 44.
In 2019, we talked about giving Memorable Tech Talks in episode 71.
In this episode, we catch up with Nina, find out what she's doing, and talk about a bunch of stuff, including:
- Live Coding
- Online Conferences
- Microsoft Python team
- Python Tea, an online hallway track
- Q&A with Python for VS Code team
- Python on hardware
- Adafruit
- Device Simulator Express
- CircuitPython
- Tricking out your command prompt
- Zsh and Oh My Zsh
- Emacs vs vi key bindings for shells
- Working from home
Special Guest: Nina Zakharenko.
Links:
- nnjaio - Twitch
- Nina Zakharenko 💜🐍 (@nnja) / Twitter
- Device Simulator Express - Visual Studio Marketplace
- Initial code for Microsoft's PyBadge at PyCon 2020
- Goodbye Print, Hello Debugger! - Nina Zakharenko - PyCon 2020 Talk
- 𝙽𝚒𝚗𝚊 𝚉𝚊𝚔𝚑𝚊𝚛𝚎𝚗𝚔𝚘 💜🐍 - DEV.to
- Python Tea Announcement
- The Live Coders Conference
That's a lot of responsibility, and to that end, the PSF Board Directors help out quite a bit.
If you want to be a part of the board, you can. There's an election coming up right around the corner and you gotta get your nomination in by May 31. You can also join the PSF if you want to vote for who gets to be part of the board.
But what does it really mean to be on the Board, and what are some of the things the PSF does?
To help answer those questions, I've got Ewa Jodlowska, the PSF Executive Director, and Christopher Neugebauer, a current board member, on the show today. I've also got some great links in the show notes if we don't answer your questions and you want to find out more.
Special Guests: Christopher Neugebauer and Ewa Jodlowska.
Links:
- Latest PSF Board Elections Discussion
- Python Software Foundation
- Overview of Elections
- Duties and Responsibilities of Directors
- Life as a Python Software Foundation Director - YouTube
That's a lot of responsibility, and to that end, the PSF Board Directors help out quite a bit.
If you want to be a part of the board, you can. There's an election coming up right around the corner and you gotta get your nomination in by May 31. You can also join the PSF if you want to vote for who gets to be part of the board.
But what does it really mean to be on the Board, and what are some of the things the PSF does?
To help answer those questions, I've got Ewa Jodlowska, the PSF Executive Director, and Christopher Neugebauer, a current board member, on the show today. I've also got some great links in the show notes if we don't answer your questions and you want to find out more.
Special Guests: Christopher Neugebauer and Ewa Jodlowska.
Links:
- Latest PSF Board Elections Discussion
- Python Software Foundation
- Overview of Elections
- Duties and Responsibilities of Directors
- Life as a Python Software Foundation Director - YouTube
That's a lot of responsibility, and to that end, the PSF Board Directors help out quite a bit.
If you want to be a part of the board, you can. There's an election coming up right around the corner and you gotta get your nomination in by May 31. You can also join the PSF if you want to vote for who gets to be part of the board.
But what does it really mean to be on the Board, and what are some of the things the PSF does?
To help answer those questions, I've got Ewa Jodlowska, the PSF Executive Director, and Christopher Neugebauer, a current board member, on the show today. I've also got some great links in the show notes if we don't answer your questions and you want to find out more.
Special Guests: Christopher Neugebauer and Ewa Jodlowska.
Links:
- Latest PSF Board Elections Discussion
- Python Software Foundation
- Overview of Elections
- Duties and Responsibilities of Directors
- Life as a Python Software Foundation Director - YouTube
The impacts of technical debt include emotional drain on engineers and slowing down development and can adversely affect your hiring ability and retention.
But really, what is technical debt? Can we measure it? How do we reduce it, and when?
James Smith, the CEO of Bugsnag, joins the show to talk about technical debt and all of these questions.
Special Guest: James Smith.
The impacts of technical debt include emotional drain on engineers and slowing down development and can adversely affect your hiring ability and retention.
But really, what is technical debt? Can we measure it? How do we reduce it, and when?
James Smith, the CEO of Bugsnag, joins the show to talk about technical debt and all of these questions.
Special Guest: James Smith.
The impacts of technical debt include emotional drain on engineers and slowing down development and can adversely affect your hiring ability and retention.
But really, what is technical debt? Can we measure it? How do we reduce it, and when?
James Smith, the CEO of Bugsnag, joins the show to talk about technical debt and all of these questions.
Special Guest: James Smith.
This is true for both production code and test code.
When you are trying to understand why a test is failing, you'll be very grateful to the test author if they've taken the care to make it readable.
David Seddon came up with 6 principles to help us write more readable tests.
We discuss these, as well as more benefits of readable tests.
David's 6 Principles of Readable Tests:
- Profit from the work of others
- Put naming to work
- Show only what matters
- Don’t repeat yourself
- Arrange, act, assert
- Aim high
Special Guest: David Seddon.
Links:
- How to write readable tests (presentation) · David Seddon
- How to write readable tests (slides)
- pytest
- WebTest
- factory_boy
- django-webtest
This is true for both production code and test code.
When you are trying to understand why a test is failing, you'll be very grateful to the test author if they've taken the care to make it readable.
David Seddon came up with 6 principles to help us write more readable tests.
We discuss these, as well as more benefits of readable tests.
David's 6 Principles of Readable Tests:
- Profit from the work of others
- Put naming to work
- Show only what matters
- Don’t repeat yourself
- Arrange, act, assert
- Aim high
Special Guest: David Seddon.
Links:
- How to write readable tests (presentation) · David Seddon
- How to write readable tests (slides)
- pytest
- WebTest
- factory_boy
- django-webtest
This is true for both production code and test code.
When you are trying to understand why a test is failing, you'll be very grateful to the test author if they've taken the care to make it readable.
David Seddon came up with 6 principles to help us write more readable tests.
We discuss these, as well as more benefits of readable tests.
David's 6 Principles of Readable Tests:
- Profit from the work of others
- Put naming to work
- Show only what matters
- Don’t repeat yourself
- Arrange, act, assert
- Aim high
Special Guest: David Seddon.
Links:
- How to write readable tests (presentation) · David Seddon
- How to write readable tests (slides)
- pytest
- WebTest
- factory_boy
- django-webtest
What if you want to keep going, and check more things?
There are a few ways. One of them is subtests.
Python's unittest introduced subtests in Python 3.4.
pytest introduced support for subtests with changes in pytest 4.4 and a plugin, called pytest-subtests.
Subtests are still not really used that much.
But really, what are they? When could you use them?
And more importantly, what should you watch out for if you decide to use them?
That's what Paul Ganssle and I will be talking about today.
Special Guest: Paul Ganssle.
Links:
- Subtests in Python — Paul's article on subtests
- subtests in unittest - Python docs
- pytest-subtests: plugin to support subtests in pytest
- pytest-check: A pytest plugin that allows multiple failures per test.
What if you want to keep going, and check more things?
There are a few ways. One of them is subtests.
Python's unittest introduced subtests in Python 3.4.
pytest introduced support for subtests with changes in pytest 4.4 and a plugin, called pytest-subtests.
Subtests are still not really used that much.
But really, what are they? When could you use them?
And more importantly, what should you watch out for if you decide to use them?
That's what Paul Ganssle and I will be talking about today.
Special Guest: Paul Ganssle.
Links:
- Subtests in Python — Paul's article on subtests
- subtests in unittest - Python docs
- pytest-subtests: plugin to support subtests in pytest
- pytest-check: A pytest plugin that allows multiple failures per test.
What if you want to keep going, and check more things?
There are a few ways. One of them is subtests.
Python's unittest introduced subtests in Python 3.4.
pytest introduced support for subtests with changes in pytest 4.4 and a plugin, called pytest-subtests.
Subtests are still not really used that much.
But really, what are they? When could you use them?
And more importantly, what should you watch out for if you decide to use them?
That's what Paul Ganssle and I will be talking about today.
Special Guest: Paul Ganssle.
Links:
- Subtests in Python — Paul's article on subtests
- subtests in unittest - Python docs
- pytest-subtests: plugin to support subtests in pytest
- pytest-check: A pytest plugin that allows multiple failures per test.
Adam Parkin, who is known online as CodependentCodr, joins us to talk about migrating an existing Django project from unittest to pytest. Adam tells us just how easy this is.
Special Guest: Adam Parkin.
Links:
- Django Tutorial, on testing
- The Django docs on testing & the test database
- The Django docs on the TestCase class
- pytest-django docs
Adam Parkin, who is known online as CodependentCodr, joins us to talk about migrating an existing Django project from unittest to pytest. Adam tells us just how easy this is.
Special Guest: Adam Parkin.
Links:
- Django Tutorial, on testing
- The Django docs on testing & the test database
- The Django docs on the TestCase class
- pytest-django docs
Adam Parkin, who is known online as CodependentCodr, joins us to talk about migrating an existing Django project from unittest to pytest. Adam tells us just how easy this is.
Special Guest: Adam Parkin.
Links:
- Django Tutorial, on testing
- The Django docs on testing & the test database
- The Django docs on the TestCase class
- pytest-django docs
Eric Bergemann joins Brian Okken to discuss:
- Specific testing challenges in the financial services domain
- CI/CD : Continuous Integration, Continuous Deployment
- TDD : Test Driven Development
- Confidence from testable applications
- Testing strategies to add coverage to legacy systems
- Testing the data and test cases themselves
- DevOps
- Continuous testing
- Manual testing procedures
- BDD & Gherkin
- Hiring in vs training industry knowledge
Special Guest: Eric Bergemann.
Links:
Eric Bergemann joins Brian Okken to discuss:
- Specific testing challenges in the financial services domain
- CI/CD : Continuous Integration, Continuous Deployment
- TDD : Test Driven Development
- Confidence from testable applications
- Testing strategies to add coverage to legacy systems
- Testing the data and test cases themselves
- DevOps
- Continuous testing
- Manual testing procedures
- BDD & Gherkin
- Hiring in vs training industry knowledge
Special Guest: Eric Bergemann.
Links:
Eric Bergemann joins Brian Okken to discuss:
- Specific testing challenges in the financial services domain
- CI/CD : Continuous Integration, Continuous Deployment
- TDD : Test Driven Development
- Confidence from testable applications
- Testing strategies to add coverage to legacy systems
- Testing the data and test cases themselves
- DevOps
- Continuous testing
- Manual testing procedures
- BDD & Gherkin
- Hiring in vs training industry knowledge
Special Guest: Eric Bergemann.
Links:
PySpark blends the powerful Spark big data processing engine with the Python programming language to provide a data analysis platform that can scale up for nearly any task.
Johnathan Rioux, author of "PySpark in Action", joins the show and gives us a great introduction of Spark and PySpark to help us decide how to get started and decide whether or not to decide if Spark and PySpark are right you.
Special Guest: Jonathan Rioux.
Links:
PySpark blends the powerful Spark big data processing engine with the Python programming language to provide a data analysis platform that can scale up for nearly any task.
Johnathan Rioux, author of "PySpark in Action", joins the show and gives us a great introduction of Spark and PySpark to help us decide how to get started and decide whether or not to decide if Spark and PySpark are right you.
Special Guest: Jonathan Rioux.
Links:
PySpark blends the powerful Spark big data processing engine with the Python programming language to provide a data analysis platform that can scale up for nearly any task.
Johnathan Rioux, author of "PySpark in Action", joins the show and gives us a great introduction of Spark and PySpark to help us decide how to get started and decide whether or not to decide if Spark and PySpark are right you.
Special Guest: Jonathan Rioux.
Links:
Hypothesis claims to combine "human understanding of your problem domain with machine intelligence to improve the quality of your testing process while spending less time writing tests."
In this episode Alexander Hultnér introduces us to property based testing in Python with Hypothesis.
Some topics covered:
- What is property based testing
- Thinking differently for property based testing
- Using hypothesis / property based testing in conjunction with normal testing
- Failures saved and re-run
- What parts of development/testing is best suited for hypothesis / property based testing
- Comparing function implementations
- Testing against REST APIs that use Open API / Swagger with schemathesis
- Changing the number of tests in different test environments
- System, integration, end to end, and unit tests
Special Guest: Alexander Hultnér.
Links:
- Hypothesis home
- Hypothesis docs
- Test Fast, Fix More - Property based testing with Hypothesis by Alexander Hultnér - YouTube
- Quickcheck, Grandfather of property based testing
- Beyond Unit Tests, Hillel Wayne, PyCon 2018
- Better Testing With Less Code, Matt Bachmann, PyCon 2016
- Choosing properties for property-based testing (F#)
- schemathesis: Hypothesis + Open API / Swagger for testing web applications
Hypothesis claims to combine "human understanding of your problem domain with machine intelligence to improve the quality of your testing process while spending less time writing tests."
In this episode Alexander Hultnér introduces us to property based testing in Python with Hypothesis.
Some topics covered:
- What is property based testing
- Thinking differently for property based testing
- Using hypothesis / property based testing in conjunction with normal testing
- Failures saved and re-run
- What parts of development/testing is best suited for hypothesis / property based testing
- Comparing function implementations
- Testing against REST APIs that use Open API / Swagger with schemathesis
- Changing the number of tests in different test environments
- System, integration, end to end, and unit tests
Special Guest: Alexander Hultnér.
Links:
- Hypothesis home
- Hypothesis docs
- Test Fast, Fix More - Property based testing with Hypothesis by Alexander Hultnér - YouTube
- Quickcheck, Grandfather of property based testing
- Beyond Unit Tests, Hillel Wayne, PyCon 2018
- Better Testing With Less Code, Matt Bachmann, PyCon 2016
- Choosing properties for property-based testing (F#)
- schemathesis: Hypothesis + Open API / Swagger for testing web applications
Hypothesis claims to combine "human understanding of your problem domain with machine intelligence to improve the quality of your testing process while spending less time writing tests."
In this episode Alexander Hultnér introduces us to property based testing in Python with Hypothesis.
Some topics covered:
- What is property based testing
- Thinking differently for property based testing
- Using hypothesis / property based testing in conjunction with normal testing
- Failures saved and re-run
- What parts of development/testing is best suited for hypothesis / property based testing
- Comparing function implementations
- Testing against REST APIs that use Open API / Swagger with schemathesis
- Changing the number of tests in different test environments
- System, integration, end to end, and unit tests
Special Guest: Alexander Hultnér.
Links:
- Hypothesis home
- Hypothesis docs
- Test Fast, Fix More - Property based testing with Hypothesis by Alexander Hultnér - YouTube
- Quickcheck, Grandfather of property based testing
- Beyond Unit Tests, Hillel Wayne, PyCon 2018
- Better Testing With Less Code, Matt Bachmann, PyCon 2016
- Choosing properties for property-based testing (F#)
- schemathesis: Hypothesis + Open API / Swagger for testing web applications
In this episode, Paul Everitt and Brian discuss ways IDEs can encourage testing and make it easier for everyone, including beginners. We discuss features that exist and are great, as well as what is missing.
The conversation also includes topics around being welcoming to new contributors for both open source and professional projects.
We talk about a lot of topics, and it's a lot of fun. But it's also important. Because IDEs can make testing
Some topics discussed:
- Making testing more accessible
- Test First vs teaching testing last
- TDD workflow
- Autorun
- Rerunning last failures
- Different ways to run different levels of tests
- Command line flags and how to access them in IDEs
- pytest.ini
- zooming in and out of test levels
- running parametrizations
- running tests with coverage and profiling
- parametrize vs parameterize
- parametrization identifiers
- pytest fixture support
- global configurations / configuration templates
- coverage and testing and being inviting to new contributors
- confidence in changes and confidence in contributions
- navigating code, tests, fixtures
- grouping tests in modules, classes, directories
- BDD, behavior driven development, cucumber, pytest-bdd
- web development testing
- parallel testing with xdist and IDE support
- refactor rename
Special Guest: Paul Everitt.
Links:
- Python Testing with pytest — The pytest book
- PyCharm
- PyCharm pro
- episode 54: Python 1994 - Paul Everitt
- pytest-xdist
In this episode, Paul Everitt and Brian discuss ways IDEs can encourage testing and make it easier for everyone, including beginners. We discuss features that exist and are great, as well as what is missing.
The conversation also includes topics around being welcoming to new contributors for both open source and professional projects.
We talk about a lot of topics, and it's a lot of fun. But it's also important. Because IDEs can make testing
Some topics discussed:
- Making testing more accessible
- Test First vs teaching testing last
- TDD workflow
- Autorun
- Rerunning last failures
- Different ways to run different levels of tests
- Command line flags and how to access them in IDEs
- pytest.ini
- zooming in and out of test levels
- running parametrizations
- running tests with coverage and profiling
- parametrize vs parameterize
- parametrization identifiers
- pytest fixture support
- global configurations / configuration templates
- coverage and testing and being inviting to new contributors
- confidence in changes and confidence in contributions
- navigating code, tests, fixtures
- grouping tests in modules, classes, directories
- BDD, behavior driven development, cucumber, pytest-bdd
- web development testing
- parallel testing with xdist and IDE support
- refactor rename
Special Guest: Paul Everitt.
Links:
- Python Testing with pytest — The pytest book
- PyCharm
- PyCharm pro
- episode 54: Python 1994 - Paul Everitt
- pytest-xdist
In this episode, Paul Everitt and Brian discuss ways IDEs can encourage testing and make it easier for everyone, including beginners. We discuss features that exist and are great, as well as what is missing.
The conversation also includes topics around being welcoming to new contributors for both open source and professional projects.
We talk about a lot of topics, and it's a lot of fun. But it's also important. Because IDEs can make testing
Some topics discussed:
- Making testing more accessible
- Test First vs teaching testing last
- TDD workflow
- Autorun
- Rerunning last failures
- Different ways to run different levels of tests
- Command line flags and how to access them in IDEs
- pytest.ini
- zooming in and out of test levels
- running parametrizations
- running tests with coverage and profiling
- parametrize vs parameterize
- parametrization identifiers
- pytest fixture support
- global configurations / configuration templates
- coverage and testing and being inviting to new contributors
- confidence in changes and confidence in contributions
- navigating code, tests, fixtures
- grouping tests in modules, classes, directories
- BDD, behavior driven development, cucumber, pytest-bdd
- web development testing
- parallel testing with xdist and IDE support
- refactor rename
Special Guest: Paul Everitt.
Links:
- Python Testing with pytest — The pytest book
- PyCharm
- PyCharm pro
- episode 54: Python 1994 - Paul Everitt
- pytest-xdist
Matt Layman has contributed to Python in many ways, including his educational newsletter, and his Django podcast, Django Riffs.
Matt is also the maintainer of tap.py and pytest-tap, two tools that bring the Test Anything Protocol to Python.
In this episode, Matt and I discuss TAP, it's history, his involvement, and some cool use cases for it.
Special Guest: Matt Layman.
Links:
- mattlayman.com
- Django Riffs, a podcast for learning Django · Matt Layman
- Test Anything Protocol
- pytest-tap: Test Anything Protocol (TAP) reporting plugin for pytest
- tappy - TAP tools for Python
Matt Layman has contributed to Python in many ways, including his educational newsletter, and his Django podcast, Django Riffs.
Matt is also the maintainer of tap.py and pytest-tap, two tools that bring the Test Anything Protocol to Python.
In this episode, Matt and I discuss TAP, it's history, his involvement, and some cool use cases for it.
Special Guest: Matt Layman.
Links:
- mattlayman.com
- Django Riffs, a podcast for learning Django · Matt Layman
- Test Anything Protocol
- pytest-tap: Test Anything Protocol (TAP) reporting plugin for pytest
- tappy - TAP tools for Python
Matt Layman has contributed to Python in many ways, including his educational newsletter, and his Django podcast, Django Riffs.
Matt is also the maintainer of tap.py and pytest-tap, two tools that bring the Test Anything Protocol to Python.
In this episode, Matt and I discuss TAP, it's history, his involvement, and some cool use cases for it.
Special Guest: Matt Layman.
Links:
- mattlayman.com
- Django Riffs, a podcast for learning Django · Matt Layman
- Test Anything Protocol
- pytest-tap: Test Anything Protocol (TAP) reporting plugin for pytest
- tappy - TAP tools for Python
In this episode, Anthony Sottile and Brian Okken discuss the top 28 pytest plugins.
Some of the plugins discussed (we also mention a few plugins related to some on this list):
- pytest-cov
- pytest-timeout
- pytest-xdist
- pytest-mock
- pytest-runner
- pytest-instafail
- pytest-django
- pytest-html
- pytest-metadata
- pytest-asyncio
- pytest-split-tests
- pytest-sugar
- pytest-rerunfailures
- pytest-env
- pytest-cache
- pytest-flask
- pytest-benchmark
- pytest-ordering
- pytest-watch
- pytest-pythonpath
- pytest-flake8
- pytest-pep8
- pytest-repeat
- pytest-pylint
- pytest-randomly
- pytest-selenium
- pytest-mypy
- pytest-freezegun
Honorable mention:
- pytest-black
- pytest-emoji
- pytest-poo
Special Guest: Anthony Sottile.
Links:
- PyPI Download Stats
- Top PyPI Packages: A monthly dump of the 4,000 most-downloaded packages from PyPI
- Test & Code 25: Selenium, pytest, Mozilla – Dave Hunt
- pre-commit
In this episode, Anthony Sottile and Brian Okken discuss the top 28 pytest plugins.
Some of the plugins discussed (we also mention a few plugins related to some on this list):
- pytest-cov
- pytest-timeout
- pytest-xdist
- pytest-mock
- pytest-runner
- pytest-instafail
- pytest-django
- pytest-html
- pytest-metadata
- pytest-asyncio
- pytest-split-tests
- pytest-sugar
- pytest-rerunfailures
- pytest-env
- pytest-cache
- pytest-flask
- pytest-benchmark
- pytest-ordering
- pytest-watch
- pytest-pythonpath
- pytest-flake8
- pytest-pep8
- pytest-repeat
- pytest-pylint
- pytest-randomly
- pytest-selenium
- pytest-mypy
- pytest-freezegun
Honorable mention:
- pytest-black
- pytest-emoji
- pytest-poo
Special Guest: Anthony Sottile.
Links:
- PyPI Download Stats
- Top PyPI Packages: A monthly dump of the 4,000 most-downloaded packages from PyPI
- Test & Code 25: Selenium, pytest, Mozilla – Dave Hunt
- pre-commit
In this episode, Anthony Sottile and Brian Okken discuss the top 28 pytest plugins.
Some of the plugins discussed (we also mention a few plugins related to some on this list):
- pytest-cov
- pytest-timeout
- pytest-xdist
- pytest-mock
- pytest-runner
- pytest-instafail
- pytest-django
- pytest-html
- pytest-metadata
- pytest-asyncio
- pytest-split-tests
- pytest-sugar
- pytest-rerunfailures
- pytest-env
- pytest-cache
- pytest-flask
- pytest-benchmark
- pytest-ordering
- pytest-watch
- pytest-pythonpath
- pytest-flake8
- pytest-pep8
- pytest-repeat
- pytest-pylint
- pytest-randomly
- pytest-selenium
- pytest-mypy
- pytest-freezegun
Honorable mention:
- pytest-black
- pytest-emoji
- pytest-poo
Special Guest: Anthony Sottile.
Links:
- PyPI Download Stats
- Top PyPI Packages: A monthly dump of the 4,000 most-downloaded packages from PyPI
- Test & Code 25: Selenium, pytest, Mozilla – Dave Hunt
- pre-commit
Topics:
- Django
- The Django Community
- Django Girls
- Django Girls Tutorial
- DjangoCon
- Software Testing
- Using tests during learning
- pytest-django
- testing Django
- Wagtail
Special Guest: Lacey Williams Henschel.
Links:
- Django
- Django Girls
- Django Girls Tutorial
- DjangoCon US 2020
- Django: Under the Hood
- PyData
- PyCascades
- Django REST framework
- pytest-django
- Wagtail CMS - Django Content Management System
Topics:
- Django
- The Django Community
- Django Girls
- Django Girls Tutorial
- DjangoCon
- Software Testing
- Using tests during learning
- pytest-django
- testing Django
- Wagtail
Special Guest: Lacey Williams Henschel.
Links:
- Django
- Django Girls
- Django Girls Tutorial
- DjangoCon US 2020
- Django: Under the Hood
- PyData
- PyCascades
- Django REST framework
- pytest-django
- Wagtail CMS - Django Content Management System
Topics:
- Django
- The Django Community
- Django Girls
- Django Girls Tutorial
- DjangoCon
- Software Testing
- Using tests during learning
- pytest-django
- testing Django
- Wagtail
Special Guest: Lacey Williams Henschel.
Links:
- Django
- Django Girls
- Django Girls Tutorial
- DjangoCon US 2020
- Django: Under the Hood
- PyData
- PyCascades
- Django REST framework
- pytest-django
- Wagtail CMS - Django Content Management System
So of course we talk about the book, also known as "Cosmic Python".
We also discuss lots of testing topics, especially related to larger systems and systems involving third party interfaces and APIs.
Topics
- Harry's new book, "Architecture Patterns with Python". a.k.a. Cosmic Python
- TDD : Test Driven Development
- Test Pyramid
- Tradeoffs of different architectural choices
- Mocks and their pitfalls
- Avoiding mocks
- Separating conceptual business logic
- Dependency injection
- Dependency inversion
- Identifying external dependencies
- Interface adapters to mimize the exposed surface area of external dependencies
- London School vs Classic/Detroit School of TDD
- Testing strategies for testing external REST APIs
Links:
]]>So of course we talk about the book, also known as "Cosmic Python".
We also discuss lots of testing topics, especially related to larger systems and systems involving third party interfaces and APIs.
Topics
- Harry's new book, "Architecture Patterns with Python". a.k.a. Cosmic Python
- TDD : Test Driven Development
- Test Pyramid
- Tradeoffs of different architectural choices
- Mocks and their pitfalls
- Avoiding mocks
- Separating conceptual business logic
- Dependency injection
- Dependency inversion
- Identifying external dependencies
- Interface adapters to mimize the exposed surface area of external dependencies
- London School vs Classic/Detroit School of TDD
- Testing strategies for testing external REST APIs
Links:
]]>So of course we talk about the book, also known as "Cosmic Python".
We also discuss lots of testing topics, especially related to larger systems and systems involving third party interfaces and APIs.
Topics
- Harry's new book, "Architecture Patterns with Python". a.k.a. Cosmic Python
- TDD : Test Driven Development
- Test Pyramid
- Tradeoffs of different architectural choices
- Mocks and their pitfalls
- Avoiding mocks
- Separating conceptual business logic
- Dependency injection
- Dependency inversion
- Identifying external dependencies
- Interface adapters to mimize the exposed surface area of external dependencies
- London School vs Classic/Detroit School of TDD
- Testing strategies for testing external REST APIs
Links:
]]>Anthony Shaw is doing something about it by creating an editor plugin that actually helps you write more secure application code while you are coding.
On today's Test & Code, Anthony and I discuss his security plugin, but also application security in general, as well as other security components you need to consider.
Security is something every team needs to think about, whether you are a single person team, a small startup, or a large corporation.
Anthony and I also discuss where to start if it's just a few of you, or even just one of you.
Topics include:
- Finding security risks while writing code.
- What are the risks for your applications.
- Thinking about attack surfaces.
- Static and dynamic code analysis.
- Securing the environment an app is running in.
- Tools for scanning live sites for vulnerabilities.
- Secret management.
- Hashing algorithms.
- Authentication systems.
- and Anthony's upcoming cPython Internals book.
Special Guest: Anthony Shaw.
Links:
Anthony Shaw is doing something about it by creating an editor plugin that actually helps you write more secure application code while you are coding.
On today's Test & Code, Anthony and I discuss his security plugin, but also application security in general, as well as other security components you need to consider.
Security is something every team needs to think about, whether you are a single person team, a small startup, or a large corporation.
Anthony and I also discuss where to start if it's just a few of you, or even just one of you.
Topics include:
- Finding security risks while writing code.
- What are the risks for your applications.
- Thinking about attack surfaces.
- Static and dynamic code analysis.
- Securing the environment an app is running in.
- Tools for scanning live sites for vulnerabilities.
- Secret management.
- Hashing algorithms.
- Authentication systems.
- and Anthony's upcoming cPython Internals book.
Special Guest: Anthony Shaw.
Links:
Anthony Shaw is doing something about it by creating an editor plugin that actually helps you write more secure application code while you are coding.
On today's Test & Code, Anthony and I discuss his security plugin, but also application security in general, as well as other security components you need to consider.
Security is something every team needs to think about, whether you are a single person team, a small startup, or a large corporation.
Anthony and I also discuss where to start if it's just a few of you, or even just one of you.
Topics include:
- Finding security risks while writing code.
- What are the risks for your applications.
- Thinking about attack surfaces.
- Static and dynamic code analysis.
- Securing the environment an app is running in.
- Tools for scanning live sites for vulnerabilities.
- Secret management.
- Hashing algorithms.
- Authentication systems.
- and Anthony's upcoming cPython Internals book.
Special Guest: Anthony Shaw.
Links:
You may want to A/B test it first to make sure you are really improving things.
But really what is A/B testing?
That's what we'll find out on this episode with Leemay Nassery.
Special Guest: Leemay Nassery.
You may want to A/B test it first to make sure you are really improving things.
But really what is A/B testing?
That's what we'll find out on this episode with Leemay Nassery.
Special Guest: Leemay Nassery.
You may want to A/B test it first to make sure you are really improving things.
But really what is A/B testing?
That's what we'll find out on this episode with Leemay Nassery.
Special Guest: Leemay Nassery.
In this episode, I talk with testmon creator Tibor Arpas about testmon, about it's use and how it works.
Special Guest: Tibor Arpas.
Links:
]]>In this episode, I talk with testmon creator Tibor Arpas about testmon, about it's use and how it works.
Special Guest: Tibor Arpas.
Links:
]]>In this episode, I talk with testmon creator Tibor Arpas about testmon, about it's use and how it works.
Special Guest: Tibor Arpas.
Links:
]]>Also, 2019 is the end of an amazingly transofrmative decade for me, so I'm going to discuss that as well.
top 10 episodes of 2019
- 10: episode 46, Testing Hard To Test Applications - Anthony Shaw
- 9: episode 64, Practicing Programming to increase your value
- 8: episode 70, Learning Software without a CS degree - Dane Hillard
- 7: episode 75, Modern Testing Principles - Alan Page
- 6: episode 72, Technical Interview Fixes - April Wensel
- 5: episode 69, Andy Hunt - The Pragmatic Programmer
- 4: episode 73, PyCon 2019 Live Recording
- 3: episode 71, Memorable Tech Talks, The Ultimate Guide - Nina Zakharenko
- 2: episode 76, TDD: Don’t be afraid of Test-Driven Development - Chris May
- 1: episode 89, Improving Programming Education - Nicholas Tollervey
Looking back on the last decade
Some amazing events, like 2 podcasts, a book, a blog, speaking events, and teaching has led me to where we're at now.
Looking forward to 2020 and beyond
I discussed what's in store in the next year and moving forward.
A closing quote
Software is a blast. At least, it should be.
I want everyone to have fun writing software.
Leaning on automated tests is the best way I know to allow me confidence and freedome to:
- rewrite big chunks of code
- play with the code
- try new things
- have fun without fear
- go home feeling good about what I did
- be proud of my code I want everyone to have that.
That's why I promote and teach automated testing.
I hope you had an amazing decade.
And I wish you a productive and fun 2020 and the upcoming decade.
If we work together and help eachother reach new heights, we can achieve some pretty amazing things
Links:
Also, 2019 is the end of an amazingly transofrmative decade for me, so I'm going to discuss that as well.
top 10 episodes of 2019
- 10: episode 46, Testing Hard To Test Applications - Anthony Shaw
- 9: episode 64, Practicing Programming to increase your value
- 8: episode 70, Learning Software without a CS degree - Dane Hillard
- 7: episode 75, Modern Testing Principles - Alan Page
- 6: episode 72, Technical Interview Fixes - April Wensel
- 5: episode 69, Andy Hunt - The Pragmatic Programmer
- 4: episode 73, PyCon 2019 Live Recording
- 3: episode 71, Memorable Tech Talks, The Ultimate Guide - Nina Zakharenko
- 2: episode 76, TDD: Don’t be afraid of Test-Driven Development - Chris May
- 1: episode 89, Improving Programming Education - Nicholas Tollervey
Looking back on the last decade
Some amazing events, like 2 podcasts, a book, a blog, speaking events, and teaching has led me to where we're at now.
Looking forward to 2020 and beyond
I discussed what's in store in the next year and moving forward.
A closing quote
Software is a blast. At least, it should be.
I want everyone to have fun writing software.
Leaning on automated tests is the best way I know to allow me confidence and freedome to:
- rewrite big chunks of code
- play with the code
- try new things
- have fun without fear
- go home feeling good about what I did
- be proud of my code I want everyone to have that.
That's why I promote and teach automated testing.
I hope you had an amazing decade.
And I wish you a productive and fun 2020 and the upcoming decade.
If we work together and help eachother reach new heights, we can achieve some pretty amazing things
Links:
Also, 2019 is the end of an amazingly transofrmative decade for me, so I'm going to discuss that as well.
top 10 episodes of 2019
- 10: episode 46, Testing Hard To Test Applications - Anthony Shaw
- 9: episode 64, Practicing Programming to increase your value
- 8: episode 70, Learning Software without a CS degree - Dane Hillard
- 7: episode 75, Modern Testing Principles - Alan Page
- 6: episode 72, Technical Interview Fixes - April Wensel
- 5: episode 69, Andy Hunt - The Pragmatic Programmer
- 4: episode 73, PyCon 2019 Live Recording
- 3: episode 71, Memorable Tech Talks, The Ultimate Guide - Nina Zakharenko
- 2: episode 76, TDD: Don’t be afraid of Test-Driven Development - Chris May
- 1: episode 89, Improving Programming Education - Nicholas Tollervey
Looking back on the last decade
Some amazing events, like 2 podcasts, a book, a blog, speaking events, and teaching has led me to where we're at now.
Looking forward to 2020 and beyond
I discussed what's in store in the next year and moving forward.
A closing quote
Software is a blast. At least, it should be.
I want everyone to have fun writing software.
Leaning on automated tests is the best way I know to allow me confidence and freedome to:
- rewrite big chunks of code
- play with the code
- try new things
- have fun without fear
- go home feeling good about what I did
- be proud of my code I want everyone to have that.
That's why I promote and teach automated testing.
I hope you had an amazing decade.
And I wish you a productive and fun 2020 and the upcoming decade.
If we work together and help eachother reach new heights, we can achieve some pretty amazing things
Links:
Special Guest: Thomas Eckert.
Links:
]]>Special Guest: Thomas Eckert.
Links:
]]>Special Guest: Thomas Eckert.
Links:
]]>Some of the software in the pipeline can be tested to some extent with traditional testing tools, like pytest.
But what about the data? The data entering the pipeline, and at various stages along the pipeline, should be validated.
That's where pipeline tests come in.
Pipeline tests are applied to data. Pipeline tests help you guard against upstream data changes and monitor data quality.
Abe Gong and Superconductive are building an open source project called Great Expectations. It's a tool to help you build pipeline tests.
This is quite an interesting idea, and I hope it gains traction and takes off.
Special Guest: Abe Gong.
Links:
]]>Some of the software in the pipeline can be tested to some extent with traditional testing tools, like pytest.
But what about the data? The data entering the pipeline, and at various stages along the pipeline, should be validated.
That's where pipeline tests come in.
Pipeline tests are applied to data. Pipeline tests help you guard against upstream data changes and monitor data quality.
Abe Gong and Superconductive are building an open source project called Great Expectations. It's a tool to help you build pipeline tests.
This is quite an interesting idea, and I hope it gains traction and takes off.
Special Guest: Abe Gong.
Links:
]]>Some of the software in the pipeline can be tested to some extent with traditional testing tools, like pytest.
But what about the data? The data entering the pipeline, and at various stages along the pipeline, should be validated.
That's where pipeline tests come in.
Pipeline tests are applied to data. Pipeline tests help you guard against upstream data changes and monitor data quality.
Abe Gong and Superconductive are building an open source project called Great Expectations. It's a tool to help you build pipeline tests.
This is quite an interesting idea, and I hope it gains traction and takes off.
Special Guest: Abe Gong.
Links:
]]>Depending on the company, you've gotta get through:
- a resume review
- a coding challange
- a phone screen
- maybe another code example
- an in person interview
If you get the job, and you enjoy the work, awesome, congratulations.
If you don't get the job, it'd be really great to know why.
Sometimes it isn't because you aren't a skilled engineer.
What other reasons are there?
Well, that's what we're talking about today.
Charity Majors is the cofounder and CTO of Honeycomb.io, and we're going to talk about reasons for not hiring someone.
This is a very informative episode both for people who job hunt in the future and for hiring managers and people on the interview team.
Special Guest: Charity Majors.
Links:
- The (Real) 11 Reasons I Don’t Hire You — The article
Depending on the company, you've gotta get through:
- a resume review
- a coding challange
- a phone screen
- maybe another code example
- an in person interview
If you get the job, and you enjoy the work, awesome, congratulations.
If you don't get the job, it'd be really great to know why.
Sometimes it isn't because you aren't a skilled engineer.
What other reasons are there?
Well, that's what we're talking about today.
Charity Majors is the cofounder and CTO of Honeycomb.io, and we're going to talk about reasons for not hiring someone.
This is a very informative episode both for people who job hunt in the future and for hiring managers and people on the interview team.
Special Guest: Charity Majors.
Links:
- The (Real) 11 Reasons I Don’t Hire You — The article
Depending on the company, you've gotta get through:
- a resume review
- a coding challange
- a phone screen
- maybe another code example
- an in person interview
If you get the job, and you enjoy the work, awesome, congratulations.
If you don't get the job, it'd be really great to know why.
Sometimes it isn't because you aren't a skilled engineer.
What other reasons are there?
Well, that's what we're talking about today.
Charity Majors is the cofounder and CTO of Honeycomb.io, and we're going to talk about reasons for not hiring someone.
This is a very informative episode both for people who job hunt in the future and for hiring managers and people on the interview team.
Special Guest: Charity Majors.
Links:
- The (Real) 11 Reasons I Don’t Hire You — The article
Andy Knight is passionate about software testing, and shares his passion through public speaking, writing on automationpanda.com, teaching as an adjunct professor, and now also through writing a book and organizing a new regional Python conference.
Topics of this episode include:
- Andy's book on software testing
- Being an adjunct professor
- Public speaking and preparing talk proposals
- including tips from Andy about proposals and preparing for talks
- PyCarolinas
Special Guest: Andy Knight.
Links:
]]>Andy Knight is passionate about software testing, and shares his passion through public speaking, writing on automationpanda.com, teaching as an adjunct professor, and now also through writing a book and organizing a new regional Python conference.
Topics of this episode include:
- Andy's book on software testing
- Being an adjunct professor
- Public speaking and preparing talk proposals
- including tips from Andy about proposals and preparing for talks
- PyCarolinas
Special Guest: Andy Knight.
Links:
]]>Andy Knight is passionate about software testing, and shares his passion through public speaking, writing on automationpanda.com, teaching as an adjunct professor, and now also through writing a book and organizing a new regional Python conference.
Topics of this episode include:
- Andy's book on software testing
- Being an adjunct professor
- Public speaking and preparing talk proposals
- including tips from Andy about proposals and preparing for talks
- PyCarolinas
Special Guest: Andy Knight.
Links:
]]>Of course, it's sarcastic, and aims to highlight many problems with organizational practices that reduce software quality.
The article doesn't go out of character, and only promotes the anti-patterns.
However, in this interview, we discuss each point, and the corollary of what you really should do. At least, our perspectives.
Here's the list of all the points discussed in the article and in this episode:
- Make the Test teams solely responsible for quality
- Require all tests to be automated before releasing
- Require 100% code coverage
- Isolate the Test organization from Development
- Measure the success of the process, not the product.
- Metrics, if rewarded, will always be gamed.
- Require granular projections from engineers
- Reward quick patching instead of solving
- Plan for today instead of tomorrow
Special Guest: Cristian Medina.
Links:
- Test Engineering Anti-Patterns: Destroy Your Customer Satisfaction and Crater Your Quality By Using These 9 Easy Organizational Practices — The article we discuss in the show.
- tryexceptpass — Cris's blog
Of course, it's sarcastic, and aims to highlight many problems with organizational practices that reduce software quality.
The article doesn't go out of character, and only promotes the anti-patterns.
However, in this interview, we discuss each point, and the corollary of what you really should do. At least, our perspectives.
Here's the list of all the points discussed in the article and in this episode:
- Make the Test teams solely responsible for quality
- Require all tests to be automated before releasing
- Require 100% code coverage
- Isolate the Test organization from Development
- Measure the success of the process, not the product.
- Metrics, if rewarded, will always be gamed.
- Require granular projections from engineers
- Reward quick patching instead of solving
- Plan for today instead of tomorrow
Special Guest: Cristian Medina.
Links:
- Test Engineering Anti-Patterns: Destroy Your Customer Satisfaction and Crater Your Quality By Using These 9 Easy Organizational Practices — The article we discuss in the show.
- tryexceptpass — Cris's blog
Of course, it's sarcastic, and aims to highlight many problems with organizational practices that reduce software quality.
The article doesn't go out of character, and only promotes the anti-patterns.
However, in this interview, we discuss each point, and the corollary of what you really should do. At least, our perspectives.
Here's the list of all the points discussed in the article and in this episode:
- Make the Test teams solely responsible for quality
- Require all tests to be automated before releasing
- Require 100% code coverage
- Isolate the Test organization from Development
- Measure the success of the process, not the product.
- Metrics, if rewarded, will always be gamed.
- Require granular projections from engineers
- Reward quick patching instead of solving
- Plan for today instead of tomorrow
Special Guest: Cristian Medina.
Links:
- Test Engineering Anti-Patterns: Destroy Your Customer Satisfaction and Crater Your Quality By Using These 9 Easy Organizational Practices — The article we discuss in the show.
- tryexceptpass — Cris's blog
On todays episode, we're going to run through what's new, picking out the bits that I think are the most interesting and affect the most people, including
- new language features
- standard library changes
- optimizations in 3.8
Not just the big stuff everyone's already talking about. But also some little things that will make programming Python even more fun and easy.
I'm excited about Python 3.8. And really, this episode is to my way to try to get you excited about it too.
Links:
]]>On todays episode, we're going to run through what's new, picking out the bits that I think are the most interesting and affect the most people, including
- new language features
- standard library changes
- optimizations in 3.8
Not just the big stuff everyone's already talking about. But also some little things that will make programming Python even more fun and easy.
I'm excited about Python 3.8. And really, this episode is to my way to try to get you excited about it too.
Links:
]]>On todays episode, we're going to run through what's new, picking out the bits that I think are the most interesting and affect the most people, including
- new language features
- standard library changes
- optimizations in 3.8
Not just the big stuff everyone's already talking about. But also some little things that will make programming Python even more fun and easy.
I'm excited about Python 3.8. And really, this episode is to my way to try to get you excited about it too.
Links:
]]>We also talk about parametrized testing and really what is fixture scope and then what is dynamic scope.
Special Guest: Anthony Sottile.
Links:
- pytest changelog
- pytest fixtures
- dynamic scope fixtures
- episode 82: pytest - favorite features since 3.0
- the pytest book — Python Testing with pytest
We also talk about parametrized testing and really what is fixture scope and then what is dynamic scope.
Special Guest: Anthony Sottile.
Links:
- pytest changelog
- pytest fixtures
- dynamic scope fixtures
- episode 82: pytest - favorite features since 3.0
- the pytest book — Python Testing with pytest
We also talk about parametrized testing and really what is fixture scope and then what is dynamic scope.
Special Guest: Anthony Sottile.
Links:
- pytest changelog
- pytest fixtures
- dynamic scope fixtures
- episode 82: pytest - favorite features since 3.0
- the pytest book — Python Testing with pytest
Special Guest: Nicholas Tollervey.
Links:
- Code With Mu — a simple Python editor for beginner programmers
- Made With Mu — A blog to celebrate projects that use the Mu Python code editor to create cool stuff.
- PyperCard — Easy GUIs for All
- CodeGrades
Special Guest: Nicholas Tollervey.
Links:
- Code With Mu — a simple Python editor for beginner programmers
- Made With Mu — A blog to celebrate projects that use the Mu Python code editor to create cool stuff.
- PyperCard — Easy GUIs for All
- CodeGrades
Special Guest: Nicholas Tollervey.
Links:
- Code With Mu — a simple Python editor for beginner programmers
- Made With Mu — A blog to celebrate projects that use the Mu Python code editor to create cool stuff.
- PyperCard — Easy GUIs for All
- CodeGrades
You've built a cool web app or service, and you want to make sure your customers have a great experience.
You know I advocate for utilizing automated tests so you find bugs before your customers do. However, fast development lifecycles, and quickly reacting to customer needs is a good thing, and we all know that complete testing is not possible. That's why I firmly believe that site monitoring tools like logging, crash reporting, performance monitoring, etc are awesome for maintaining and improving user experience.
John-Daniel Trask, JD, the CEO of Raygun, agreed to come on the show and let me ask all my questions about this whole field.
Special Guest: John-Daniel Trask.
]]>You've built a cool web app or service, and you want to make sure your customers have a great experience.
You know I advocate for utilizing automated tests so you find bugs before your customers do. However, fast development lifecycles, and quickly reacting to customer needs is a good thing, and we all know that complete testing is not possible. That's why I firmly believe that site monitoring tools like logging, crash reporting, performance monitoring, etc are awesome for maintaining and improving user experience.
John-Daniel Trask, JD, the CEO of Raygun, agreed to come on the show and let me ask all my questions about this whole field.
Special Guest: John-Daniel Trask.
]]>You've built a cool web app or service, and you want to make sure your customers have a great experience.
You know I advocate for utilizing automated tests so you find bugs before your customers do. However, fast development lifecycles, and quickly reacting to customer needs is a good thing, and we all know that complete testing is not possible. That's why I firmly believe that site monitoring tools like logging, crash reporting, performance monitoring, etc are awesome for maintaining and improving user experience.
John-Daniel Trask, JD, the CEO of Raygun, agreed to come on the show and let me ask all my questions about this whole field.
Special Guest: John-Daniel Trask.
]]>It's totally one of the superpowers of pytest.
It's actually a handful of features, and there are a few ways to approach it.
Parametrization is the ability to take one test, and send lots of different input datasets into the code under test, and maybe even have different output checks, all within the same test that you developed in the simple test case.
Super powerful, but something since there's a few approaches to it, a tad tricky to get the hang of.
Links:
- git branch — -a : list all branches, -r : just remotes
- pytest changelog
- pytest deprecations and removals
- Python Testing with pytest — Test function parametrization is in chapter 2. Fixture parametrization is in chapter 3.
- Parametrizing test functions — pytest documentation
- pytest fixtures — pytest documentation
It's totally one of the superpowers of pytest.
It's actually a handful of features, and there are a few ways to approach it.
Parametrization is the ability to take one test, and send lots of different input datasets into the code under test, and maybe even have different output checks, all within the same test that you developed in the simple test case.
Super powerful, but something since there's a few approaches to it, a tad tricky to get the hang of.
Links:
- git branch — -a : list all branches, -r : just remotes
- pytest changelog
- pytest deprecations and removals
- Python Testing with pytest — Test function parametrization is in chapter 2. Fixture parametrization is in chapter 3.
- Parametrizing test functions — pytest documentation
- pytest fixtures — pytest documentation
It's totally one of the superpowers of pytest.
It's actually a handful of features, and there are a few ways to approach it.
Parametrization is the ability to take one test, and send lots of different input datasets into the code under test, and maybe even have different output checks, all within the same test that you developed in the simple test case.
Super powerful, but something since there's a few approaches to it, a tad tricky to get the hang of.
Links:
- git branch — -a : list all branches, -r : just remotes
- pytest changelog
- pytest deprecations and removals
- Python Testing with pytest — Test function parametrization is in chapter 2. Fixture parametrization is in chapter 3.
- Parametrizing test functions — pytest documentation
- pytest fixtures — pytest documentation
Awesome.
Now your colleagues want in on that super power and want to learn testing.
How do you help them?
That's where Josh Peak is. He's helping his team add testing to their workflow to boost their productivity.
That's what we're talking about today on Test & Code.
Josh walks us through 4 maxims of developing software tests that help grow your confidence and proficiency at test writing.
Special Guest: Josh Peak.
Links:
]]>Awesome.
Now your colleagues want in on that super power and want to learn testing.
How do you help them?
That's where Josh Peak is. He's helping his team add testing to their workflow to boost their productivity.
That's what we're talking about today on Test & Code.
Josh walks us through 4 maxims of developing software tests that help grow your confidence and proficiency at test writing.
Special Guest: Josh Peak.
Links:
]]>Awesome.
Now your colleagues want in on that super power and want to learn testing.
How do you help them?
That's where Josh Peak is. He's helping his team add testing to their workflow to boost their productivity.
That's what we're talking about today on Test & Code.
Josh walks us through 4 maxims of developing software tests that help grow your confidence and proficiency at test writing.
Special Guest: Josh Peak.
Links:
]]>Software test suites grow from small quick suites at the beginning of a project to larger suites as we add tests, and the time to run the suites grows with it.
Fortunately, pytest has many tricks up it's sleave to help shorten those test suite times.
Niklas Meinzer is a software developer that recentely wrote an article on optimizing test suites. In this episode, I talk with Niklas about the optimization techniques discussed in the article and how they can apply to just about any project.
Special Guest: Niklas Meinzer.
Links:
]]>Software test suites grow from small quick suites at the beginning of a project to larger suites as we add tests, and the time to run the suites grows with it.
Fortunately, pytest has many tricks up it's sleave to help shorten those test suite times.
Niklas Meinzer is a software developer that recentely wrote an article on optimizing test suites. In this episode, I talk with Niklas about the optimization techniques discussed in the article and how they can apply to just about any project.
Special Guest: Niklas Meinzer.
Links:
]]>Software test suites grow from small quick suites at the beginning of a project to larger suites as we add tests, and the time to run the suites grows with it.
Fortunately, pytest has many tricks up it's sleave to help shorten those test suite times.
Niklas Meinzer is a software developer that recentely wrote an article on optimizing test suites. In this episode, I talk with Niklas about the optimization techniques discussed in the article and how they can apply to just about any project.
Special Guest: Niklas Meinzer.
Links:
]]>With CircuitPython, these projects can now use Python.
The combination of Python's ease of use and Adafruit's super cool hardware and a focus on a successful beginner experience makes learning to write code that controls hardware super fun.
In this episode, Scott Shawcroft, the project lead, talks about the past, present, and future of CircuitPython, and discusses the focus on the beginner.
We also discuss contributing to the project, testing CircuitPython, and many of the cool projects and hardware boards that can use CircuitPython, and Blinka, a library to allow you to use "CircuitPython APIs for non-CircuitPython versions of Python such as CPython on Linux and MicroPython," including Raspberry Pi.
Special Guest: Scott Shawcroft.
Links:
]]>With CircuitPython, these projects can now use Python.
The combination of Python's ease of use and Adafruit's super cool hardware and a focus on a successful beginner experience makes learning to write code that controls hardware super fun.
In this episode, Scott Shawcroft, the project lead, talks about the past, present, and future of CircuitPython, and discusses the focus on the beginner.
We also discuss contributing to the project, testing CircuitPython, and many of the cool projects and hardware boards that can use CircuitPython, and Blinka, a library to allow you to use "CircuitPython APIs for non-CircuitPython versions of Python such as CPython on Linux and MicroPython," including Raspberry Pi.
Special Guest: Scott Shawcroft.
Links:
]]>With CircuitPython, these projects can now use Python.
The combination of Python's ease of use and Adafruit's super cool hardware and a focus on a successful beginner experience makes learning to write code that controls hardware super fun.
In this episode, Scott Shawcroft, the project lead, talks about the past, present, and future of CircuitPython, and discusses the focus on the beginner.
We also discuss contributing to the project, testing CircuitPython, and many of the cool projects and hardware boards that can use CircuitPython, and Blinka, a library to allow you to use "CircuitPython APIs for non-CircuitPython versions of Python such as CPython on Linux and MicroPython," including Raspberry Pi.
Special Guest: Scott Shawcroft.
Links:
]]>They started doing code challanges along with people around the world and writing about it.
Then came the codechalleng.es platform, where you can do code challenges in the browser and have your answer checked by pytest tests. But how does it all work?
Bob joins me today to go behind the scenes and share the tech stack running the PyBites Code Challenges platform.
We talk about the technology, the testing, and how it went from a cool idea to a working platform.
Special Guest: Bob Belderbos.
Links:
]]>They started doing code challanges along with people around the world and writing about it.
Then came the codechalleng.es platform, where you can do code challenges in the browser and have your answer checked by pytest tests. But how does it all work?
Bob joins me today to go behind the scenes and share the tech stack running the PyBites Code Challenges platform.
We talk about the technology, the testing, and how it went from a cool idea to a working platform.
Special Guest: Bob Belderbos.
Links:
]]>They started doing code challanges along with people around the world and writing about it.
Then came the codechalleng.es platform, where you can do code challenges in the browser and have your answer checked by pytest tests. But how does it all work?
Bob joins me today to go behind the scenes and share the tech stack running the PyBites Code Challenges platform.
We talk about the technology, the testing, and how it went from a cool idea to a working platform.
Special Guest: Bob Belderbos.
Links:
]]>many other projects. In this episode, Anthony shares some of the super cool features of pytest that have been added since he started using it.
We also discuss Anthony's move from user to contributor, and how others can help with the pytest project.
Special Guest: Anthony Sottile.
Links:
]]>many other projects. In this episode, Anthony shares some of the super cool features of pytest that have been added since he started using it.
We also discuss Anthony's move from user to contributor, and how others can help with the pytest project.
Special Guest: Anthony Sottile.
Links:
]]>many other projects. In this episode, Anthony shares some of the super cool features of pytest that have been added since he started using it.
We also discuss Anthony's move from user to contributor, and how others can help with the pytest project.
Special Guest: Anthony Sottile.
Links:
]]>I worked on a project called subark and did the packaging with flit.
Today's episode is a continuation where we add new features to a supported package and how to develop and test a flit based package.
Covered:
- viewing stages of a project with git tags
- flit support for editable installs
- flit description entry in pyproject.toml to put README on pypi.
- development dependencies in pyproject.toml
- editor layout for optimal TDD-ing
- test case grouping
- modifications to traditional TDD that helps me develop faster.
code and command snippets from episode:
For git checkout of versions:
$ git clone https://github.com/okken/submark.git $ cd submark $ python3 -m venv venv --prompt submark $ source ./bin/activate (submark) $ git checkout v0.1 ... etc ... (submark) $ git checkout v0.7To grab the latest again:
(submark) $ git checkout masterpyproject.toml change for README to show up on pypi:
[tool.flit.metadata] ... description-file = "README.md" ...Adding dev dependencies to pyproject.toml:
[tool.flit.metadata.requires-extra] test = ["pytest", "pytest-cov", "tox"]Installing in editable mode (in top level repo directory). works in mac, linux, windows:
(submark) $ flit install --pth-fileor for mac/linux:
(submark) $ flit install -sLinks:
]]>I worked on a project called subark and did the packaging with flit.
Today's episode is a continuation where we add new features to a supported package and how to develop and test a flit based package.
Covered:
- viewing stages of a project with git tags
- flit support for editable installs
- flit description entry in pyproject.toml to put README on pypi.
- development dependencies in pyproject.toml
- editor layout for optimal TDD-ing
- test case grouping
- modifications to traditional TDD that helps me develop faster.
code and command snippets from episode:
For git checkout of versions:
$ git clone https://github.com/okken/submark.git $ cd submark $ python3 -m venv venv --prompt submark $ source ./bin/activate (submark) $ git checkout v0.1 ... etc ... (submark) $ git checkout v0.7To grab the latest again:
(submark) $ git checkout masterpyproject.toml change for README to show up on pypi:
[tool.flit.metadata] ... description-file = "README.md" ...Adding dev dependencies to pyproject.toml:
[tool.flit.metadata.requires-extra] test = ["pytest", "pytest-cov", "tox"]Installing in editable mode (in top level repo directory). works in mac, linux, windows:
(submark) $ flit install --pth-fileor for mac/linux:
(submark) $ flit install -sLinks:
]]>I worked on a project called subark and did the packaging with flit.
Today's episode is a continuation where we add new features to a supported package and how to develop and test a flit based package.
Covered:
- viewing stages of a project with git tags
- flit support for editable installs
- flit description entry in pyproject.toml to put README on pypi.
- development dependencies in pyproject.toml
- editor layout for optimal TDD-ing
- test case grouping
- modifications to traditional TDD that helps me develop faster.
code and command snippets from episode:
For git checkout of versions:
$ git clone https://github.com/okken/submark.git $ cd submark $ python3 -m venv venv --prompt submark $ source ./bin/activate (submark) $ git checkout v0.1 ... etc ... (submark) $ git checkout v0.7To grab the latest again:
(submark) $ git checkout masterpyproject.toml change for README to show up on pypi:
[tool.flit.metadata] ... description-file = "README.md" ...Adding dev dependencies to pyproject.toml:
[tool.flit.metadata.requires-extra] test = ["pytest", "pytest-cov", "tox"]Installing in editable mode (in top level repo directory). works in mac, linux, windows:
(submark) $ flit install --pth-fileor for mac/linux:
(submark) $ flit install -sLinks:
]]>And an alternate solution to "using the src".
Python makes it easy to build simple tools for all kinds of tasks.
And it's great to be able to share small projects with others on your team, in your company, or with the world.
When you want to take a script from "just a script" to maintainable package, there are a few steps, but none of it's hard.
Also, the structure of the code layout changes to help with the growth and support.
Instead of just talking about this from memory, I thought it'd be fun to create a new project and walk through the steps, and report back in a kind of time lapse episode. It should be fun.
Here are the steps we walk through:
- 0.1 Initial script and tests
- 0.2 build wheel with flit
- 0.3 build and test with tox
- 0.4 move source module into a package directory
- 0.5 move tests into tests directory
Links:
]]>And an alternate solution to "using the src".
Python makes it easy to build simple tools for all kinds of tasks.
And it's great to be able to share small projects with others on your team, in your company, or with the world.
When you want to take a script from "just a script" to maintainable package, there are a few steps, but none of it's hard.
Also, the structure of the code layout changes to help with the growth and support.
Instead of just talking about this from memory, I thought it'd be fun to create a new project and walk through the steps, and report back in a kind of time lapse episode. It should be fun.
Here are the steps we walk through:
- 0.1 Initial script and tests
- 0.2 build wheel with flit
- 0.3 build and test with tox
- 0.4 move source module into a package directory
- 0.5 move tests into tests directory
Links:
]]>And an alternate solution to "using the src".
Python makes it easy to build simple tools for all kinds of tasks.
And it's great to be able to share small projects with others on your team, in your company, or with the world.
When you want to take a script from "just a script" to maintainable package, there are a few steps, but none of it's hard.
Also, the structure of the code layout changes to help with the growth and support.
Instead of just talking about this from memory, I thought it'd be fun to create a new project and walk through the steps, and report back in a kind of time lapse episode. It should be fun.
Here are the steps we walk through:
- 0.1 Initial script and tests
- 0.2 build wheel with flit
- 0.3 build and test with tox
- 0.4 move source module into a package directory
- 0.5 move tests into tests directory
Links:
]]>I'm not talking about opinions. I have lots of opinions and they differ from other peoples opinions. I'm talking about misinformation and old information that is no longer applicable.
I've ran across a few lateley that I want to address.
All of the following are wrong:
- Integrated tests can't work. I can prove it with wacky math.
- Tests have to be blazing fast or they won't get run.
- TDD is about design, not about testing.
This episode discusses why these are wrong.
Links:
- Why should you write tests? - A Question of Code Podcast
- Boundaries talk by Gary Bernhardt
- Integrated Tests Are A Scam - J B Rainsberger
- UnitTest - Solitary or Sociable - and speed - Martin Fowler
- Premature optimization is the root of all evil -- DonaldKnuth
- My reaction to "Is TDD Dead?" - Python Testing
- Test-induced design damage - DHH
- Slow database test fallacy - DHH
- RailsConf 2014 - Keynote: Writing Software - DHH
- Manifesto for Agile Software Development
- Apache Beam Contrib Guide, including post commit testing
I'm not talking about opinions. I have lots of opinions and they differ from other peoples opinions. I'm talking about misinformation and old information that is no longer applicable.
I've ran across a few lateley that I want to address.
All of the following are wrong:
- Integrated tests can't work. I can prove it with wacky math.
- Tests have to be blazing fast or they won't get run.
- TDD is about design, not about testing.
This episode discusses why these are wrong.
Links:
- Why should you write tests? - A Question of Code Podcast
- Boundaries talk by Gary Bernhardt
- Integrated Tests Are A Scam - J B Rainsberger
- UnitTest - Solitary or Sociable - and speed - Martin Fowler
- Premature optimization is the root of all evil -- DonaldKnuth
- My reaction to "Is TDD Dead?" - Python Testing
- Test-induced design damage - DHH
- Slow database test fallacy - DHH
- RailsConf 2014 - Keynote: Writing Software - DHH
- Manifesto for Agile Software Development
- Apache Beam Contrib Guide, including post commit testing
I'm not talking about opinions. I have lots of opinions and they differ from other peoples opinions. I'm talking about misinformation and old information that is no longer applicable.
I've ran across a few lateley that I want to address.
All of the following are wrong:
- Integrated tests can't work. I can prove it with wacky math.
- Tests have to be blazing fast or they won't get run.
- TDD is about design, not about testing.
This episode discusses why these are wrong.
Links:
- Why should you write tests? - A Question of Code Podcast
- Boundaries talk by Gary Bernhardt
- Integrated Tests Are A Scam - J B Rainsberger
- UnitTest - Solitary or Sociable - and speed - Martin Fowler
- Premature optimization is the root of all evil -- DonaldKnuth
- My reaction to "Is TDD Dead?" - Python Testing
- Test-induced design damage - DHH
- Slow database test fallacy - DHH
- RailsConf 2014 - Keynote: Writing Software - DHH
- Manifesto for Agile Software Development
- Apache Beam Contrib Guide, including post commit testing
Some developers either don't write tests, or don't like writing tests.
Why not? I love writing tests.
In this episode we examine lots of roadblocks to testing, and start coming up with solutions for these.
Links:
]]>Some developers either don't write tests, or don't like writing tests.
Why not? I love writing tests.
In this episode we examine lots of roadblocks to testing, and start coming up with solutions for these.
Links:
]]>Some developers either don't write tests, or don't like writing tests.
Why not? I love writing tests.
In this episode we examine lots of roadblocks to testing, and start coming up with solutions for these.
Links:
]]>- quick overview of what test instruments are
- discussion of API and communication with instruments
- techniques for shifting complexity out of test cases
These techniques should apply to all test suites dealing with complex systems:
- Creating test cases that are easy to read and debug and tell a story about what is being tested.
- Pushing setup complexity into fixtures.
- Pushing lengthy repetitive API call sets into helper functions.
- Using stable, documented, interfaces.
Links:
- Voltmeter
- Oscilloscope
- Spectrum analyzer
- Function generator
- Arbitrary waveform generator
- Wireless Communications Testers & Systems
- R&S CMW Platform
- SCPI - Standard Commands for Programmable Instruments
- VISA - Virtual instrument software architecture
- PyVISA: Control your instruments with Python
- pytest
- pytest book
- quick overview of what test instruments are
- discussion of API and communication with instruments
- techniques for shifting complexity out of test cases
These techniques should apply to all test suites dealing with complex systems:
- Creating test cases that are easy to read and debug and tell a story about what is being tested.
- Pushing setup complexity into fixtures.
- Pushing lengthy repetitive API call sets into helper functions.
- Using stable, documented, interfaces.
Links:
- Voltmeter
- Oscilloscope
- Spectrum analyzer
- Function generator
- Arbitrary waveform generator
- Wireless Communications Testers & Systems
- R&S CMW Platform
- SCPI - Standard Commands for Programmable Instruments
- VISA - Virtual instrument software architecture
- PyVISA: Control your instruments with Python
- pytest
- pytest book
- quick overview of what test instruments are
- discussion of API and communication with instruments
- techniques for shifting complexity out of test cases
These techniques should apply to all test suites dealing with complex systems:
- Creating test cases that are easy to read and debug and tell a story about what is being tested.
- Pushing setup complexity into fixtures.
- Pushing lengthy repetitive API call sets into helper functions.
- Using stable, documented, interfaces.
Links:
- Voltmeter
- Oscilloscope
- Spectrum analyzer
- Function generator
- Arbitrary waveform generator
- Wireless Communications Testers & Systems
- R&S CMW Platform
- SCPI - Standard Commands for Programmable Instruments
- VISA - Virtual instrument software architecture
- PyVISA: Control your instruments with Python
- pytest
- pytest book
Why is that? And how can we make it less scary?
That's what this episode is about.
Chris May is a Python developer and the co-founder of PyRVA, the Richmond Virginia Python group.
In this episode, Chris shares his experience with adding testing and TDD to his work flow.
I really enjoyed talking with Chris, and I think his story will help lots of people overcome testing anxiety.
Special Guest: Chris May.
Links:
]]>Why is that? And how can we make it less scary?
That's what this episode is about.
Chris May is a Python developer and the co-founder of PyRVA, the Richmond Virginia Python group.
In this episode, Chris shares his experience with adding testing and TDD to his work flow.
I really enjoyed talking with Chris, and I think his story will help lots of people overcome testing anxiety.
Special Guest: Chris May.
Links:
]]>Why is that? And how can we make it less scary?
That's what this episode is about.
Chris May is a Python developer and the co-founder of PyRVA, the Richmond Virginia Python group.
In this episode, Chris shares his experience with adding testing and TDD to his work flow.
I really enjoyed talking with Chris, and I think his story will help lots of people overcome testing anxiety.
Special Guest: Chris May.
Links:
]]>One of the people at the forefront of this push is Alan Page. Alan and his podcast cohost Brent Jensen tried to boil down what modern testing looks like in the Modern Testing Principles.
I've got Alan here today, to talk about the principles, and also to talk about this transition from classical QA to testing specialists being embedded in software teams and then to software teams doing their own testing.
But that only barely scratches the surface of what we cover. I think you'll learn a lot from this discussion.
The seven principles of Modern Testing:
- Our priority is improving the business.
- We accelerate the team, and use models like Lean Thinking and the Theory of Constraints to help identify, prioritize and mitigate bottlenecks from the system.
- We are a force for continuous improvement, helping the team adapt and optimize in order to succeed, rather than providing a safety net to catch failures.
- We care deeply about the quality culture of our team, and we coach, lead, and nurture the team towards a more mature quality culture.
- We believe that the customer is the only one capable to judge and evaluate the quality of our product
- We use data extensively to deeply understand customer usage and then close the gaps between product hypotheses and business impact.
- We expand testing abilities and knowhow across the team; understanding that this may reduce (or eliminate) the need for a dedicated testing specialist.
Special Guest: Alan Page.
Links:
]]>One of the people at the forefront of this push is Alan Page. Alan and his podcast cohost Brent Jensen tried to boil down what modern testing looks like in the Modern Testing Principles.
I've got Alan here today, to talk about the principles, and also to talk about this transition from classical QA to testing specialists being embedded in software teams and then to software teams doing their own testing.
But that only barely scratches the surface of what we cover. I think you'll learn a lot from this discussion.
The seven principles of Modern Testing:
- Our priority is improving the business.
- We accelerate the team, and use models like Lean Thinking and the Theory of Constraints to help identify, prioritize and mitigate bottlenecks from the system.
- We are a force for continuous improvement, helping the team adapt and optimize in order to succeed, rather than providing a safety net to catch failures.
- We care deeply about the quality culture of our team, and we coach, lead, and nurture the team towards a more mature quality culture.
- We believe that the customer is the only one capable to judge and evaluate the quality of our product
- We use data extensively to deeply understand customer usage and then close the gaps between product hypotheses and business impact.
- We expand testing abilities and knowhow across the team; understanding that this may reduce (or eliminate) the need for a dedicated testing specialist.
Special Guest: Alan Page.
Links:
]]>One of the people at the forefront of this push is Alan Page. Alan and his podcast cohost Brent Jensen tried to boil down what modern testing looks like in the Modern Testing Principles.
I've got Alan here today, to talk about the principles, and also to talk about this transition from classical QA to testing specialists being embedded in software teams and then to software teams doing their own testing.
But that only barely scratches the surface of what we cover. I think you'll learn a lot from this discussion.
The seven principles of Modern Testing:
- Our priority is improving the business.
- We accelerate the team, and use models like Lean Thinking and the Theory of Constraints to help identify, prioritize and mitigate bottlenecks from the system.
- We are a force for continuous improvement, helping the team adapt and optimize in order to succeed, rather than providing a safety net to catch failures.
- We care deeply about the quality culture of our team, and we coach, lead, and nurture the team towards a more mature quality culture.
- We believe that the customer is the only one capable to judge and evaluate the quality of our product
- We use data extensively to deeply understand customer usage and then close the gaps between product hypotheses and business impact.
- We expand testing abilities and knowhow across the team; understanding that this may reduce (or eliminate) the need for a dedicated testing specialist.
Special Guest: Alan Page.
Links:
]]>This is the episode you need to listen to to get ready for software interviews.
We discuss four aspects of technical interviews that interviewers are looking for:
- communication
- problem solving
- coding
- verification
How to practice for the interview.
Techniques for synchronizing with interviewer and asking for hints.
Even how to ask the recruiter or hiring manager how to prepare for the interview.
If you or anyone you know has a software interview coming up, this episode will help you both feel more comfortable about the interview before you show up, and give you concrete tips on how to do better during the interview.
Special Guest: Derrick Mar.
Links:
]]>This is the episode you need to listen to to get ready for software interviews.
We discuss four aspects of technical interviews that interviewers are looking for:
- communication
- problem solving
- coding
- verification
How to practice for the interview.
Techniques for synchronizing with interviewer and asking for hints.
Even how to ask the recruiter or hiring manager how to prepare for the interview.
If you or anyone you know has a software interview coming up, this episode will help you both feel more comfortable about the interview before you show up, and give you concrete tips on how to do better during the interview.
Special Guest: Derrick Mar.
Links:
]]>This is the episode you need to listen to to get ready for software interviews.
We discuss four aspects of technical interviews that interviewers are looking for:
- communication
- problem solving
- coding
- verification
How to practice for the interview.
Techniques for synchronizing with interviewer and asking for hints.
Even how to ask the recruiter or hiring manager how to prepare for the interview.
If you or anyone you know has a software interview coming up, this episode will help you both feel more comfortable about the interview before you show up, and give you concrete tips on how to do better during the interview.
Special Guest: Derrick Mar.
]]>PyCon is very important to me.
But it's kinda hard to put a finger on why.
So I figured I'd ask more people to help explain why it's important.
I ask a few simple questions to people about Python and PyCon and get some great insights into both the language popularity and the special place this conference holds to many people.]]>
PyCon is very important to me.
But it's kinda hard to put a finger on why.
So I figured I'd ask more people to help explain why it's important.
I ask a few simple questions to people about Python and PyCon and get some great insights into both the language popularity and the special place this conference holds to many people.]]>
PyCon is very important to me.
But it's kinda hard to put a finger on why.
So I figured I'd ask more people to help explain why it's important.
I ask a few simple questions to people about Python and PyCon and get some great insights into both the language popularity and the special place this conference holds to many people.]]>
She recommends:
- hire for mindset and attitude
- look for empathy and mentorship skills
- allow candidates to show their strengths instead of hunting for weaknesses
- have the candidate leave feeling good about themselves and your company, regardless of the hiring decision
Some topics discussed:
- interview questions to bring out stories of skills and successes
- stereotype threat
- diversity
- interview hazing
- white boards
- coding challenges
- unconscious bias
- emotional intelligence
- myth of talent shortage
- pair programming and collaboration during interviews
- mirrortocracy
- cultural add vs cultural fit
- empathy
- mentoring
This episode is important for anyone going into a technical interview, as a candidate, as a hiring manager, or as a member of an interview team.
Special Guest: April Wensel.
Links:
]]>She recommends:
- hire for mindset and attitude
- look for empathy and mentorship skills
- allow candidates to show their strengths instead of hunting for weaknesses
- have the candidate leave feeling good about themselves and your company, regardless of the hiring decision
Some topics discussed:
- interview questions to bring out stories of skills and successes
- stereotype threat
- diversity
- interview hazing
- white boards
- coding challenges
- unconscious bias
- emotional intelligence
- myth of talent shortage
- pair programming and collaboration during interviews
- mirrortocracy
- cultural add vs cultural fit
- empathy
- mentoring
This episode is important for anyone going into a technical interview, as a candidate, as a hiring manager, or as a member of an interview team.
Special Guest: April Wensel.
Links:
]]>She recommends:
- hire for mindset and attitude
- look for empathy and mentorship skills
- allow candidates to show their strengths instead of hunting for weaknesses
- have the candidate leave feeling good about themselves and your company, regardless of the hiring decision
Some topics discussed:
- interview questions to bring out stories of skills and successes
- stereotype threat
- diversity
- interview hazing
- white boards
- coding challenges
- unconscious bias
- emotional intelligence
- myth of talent shortage
- pair programming and collaboration during interviews
- mirrortocracy
- cultural add vs cultural fit
- empathy
- mentoring
This episode is important for anyone going into a technical interview, as a candidate, as a hiring manager, or as a member of an interview team.
Special Guest: April Wensel.
Links:
]]>We talk about a blog series that Nina wrote called "The Ultimate Guide To Memorable Tech Talks". This episode is full of great help and encouragement for your own public speaking adventures.
Some of what we discuss:
- overcoming the fear of public speaking
- breathing and pausing during talks
- planning your talk as well as planning your time to get ready for the talk
- writing proposals and getting feedback on proposals
- Nina's talk in PyCascades on programming Adafruit chips
- types of talks that are often rejected
- pre-recording demos to avoid live demo problems
- why you should speak, even if you are an introvert
- benefits of public speaking
- a super cool announcement at the end
Special Guest: Nina Zakharenko.
Links:
- The Ultimate Guide To Memorable Tech Talks — Nina's series of posts with lots of advice on giving excellent tech talks.
- Azure for Python developers — Tutorials, API Reference | Microsoft Docs
- How to Do a Deep, Diaphragmatic Belly Breathing
- Example accepted and rejected conference talk proposals — Nina's examples
- Allison Kaptur's PyCon Proposal examples
- Emily Morehouse's proposal examples.
- Brandon Rhodes' example PyCon talk proposals
- Nina's PyCascades talk on Python and LEDs — PyCascades – Light Up Your Life – With Python and LEDs, starts at 13:26.
- Nina has a keynote at PyCon 2019 — woohoo!
We talk about a blog series that Nina wrote called "The Ultimate Guide To Memorable Tech Talks". This episode is full of great help and encouragement for your own public speaking adventures.
Some of what we discuss:
- overcoming the fear of public speaking
- breathing and pausing during talks
- planning your talk as well as planning your time to get ready for the talk
- writing proposals and getting feedback on proposals
- Nina's talk in PyCascades on programming Adafruit chips
- types of talks that are often rejected
- pre-recording demos to avoid live demo problems
- why you should speak, even if you are an introvert
- benefits of public speaking
- a super cool announcement at the end
Special Guest: Nina Zakharenko.
Links:
- The Ultimate Guide To Memorable Tech Talks — Nina's series of posts with lots of advice on giving excellent tech talks.
- Azure for Python developers — Tutorials, API Reference | Microsoft Docs
- How to Do a Deep, Diaphragmatic Belly Breathing
- Example accepted and rejected conference talk proposals — Nina's examples
- Allison Kaptur's PyCon Proposal examples
- Emily Morehouse's proposal examples.
- Brandon Rhodes' example PyCon talk proposals
- Nina's PyCascades talk on Python and LEDs — PyCascades – Light Up Your Life – With Python and LEDs, starts at 13:26.
- Nina has a keynote at PyCon 2019 — woohoo!
We talk about a blog series that Nina wrote called "The Ultimate Guide To Memorable Tech Talks". This episode is full of great help and encouragement for your own public speaking adventures.
Some of what we discuss:
- overcoming the fear of public speaking
- breathing and pausing during talks
- planning your talk as well as planning your time to get ready for the talk
- writing proposals and getting feedback on proposals
- Nina's talk in PyCascades on programming Adafruit chips
- types of talks that are often rejected
- pre-recording demos to avoid live demo problems
- why you should speak, even if you are an introvert
- benefits of public speaking
- a super cool announcement at the end
Special Guest: Nina Zakharenko.
Links:
- The Ultimate Guide To Memorable Tech Talks — Nina's series of posts with lots of advice on giving excellent tech talks.
- Azure for Python developers — Tutorials, API Reference | Microsoft Docs
- How to Do a Deep, Diaphragmatic Belly Breathing
- Example accepted and rejected conference talk proposals — Nina's examples
- Allison Kaptur's PyCon Proposal examples
- Emily Morehouse's proposal examples.
- Brandon Rhodes' example PyCon talk proposals
- Nina's PyCascades talk on Python and LEDs — PyCascades – Light Up Your Life – With Python and LEDs, starts at 13:26.
- Nina has a keynote at PyCon 2019 — woohoo!
Dane is also writing a book to address many of these skill gaps, Code Like a Pro, that's currently in an early access phase. Use code podtest&code19 to get a discount. And, sign up as a Friend of the Show to enter for a chance to win a free copy of the eBook version.
We also discuss the writing process, testing with a multi-language stack, music, art, photography, and more.
Special Guest: Dane Hillard.
Links:
- Dane Hillard
- Code Like a Pro — Dane's book
- Noisely
- Little Leviathan — Dane's music
- Dane Hillard Photography — Dane's photography
- Nvidia AI turns sketches into photorealistic landscapes in seconds
Dane is also writing a book to address many of these skill gaps, Code Like a Pro, that's currently in an early access phase. Use code podtest&code19 to get a discount. And, sign up as a Friend of the Show to enter for a chance to win a free copy of the eBook version.
We also discuss the writing process, testing with a multi-language stack, music, art, photography, and more.
Special Guest: Dane Hillard.
Links:
- Dane Hillard
- Code Like a Pro — Dane's book
- Noisely
- Little Leviathan — Dane's music
- Dane Hillard Photography — Dane's photography
- Nvidia AI turns sketches into photorealistic landscapes in seconds
Dane is also writing a book to address many of these skill gaps, Code Like a Pro, that's currently in an early access phase. Use code podtest&code19 to get a discount. And, sign up as a Friend of the Show to enter for a chance to win a free copy of the eBook version.
We also discuss the writing process, testing with a multi-language stack, music, art, photography, and more.
Special Guest: Dane Hillard.
Links:
- Dane Hillard
- Code Like a Pro — Dane's book
- Noisely
- Little Leviathan — Dane's music
- Dane Hillard Photography — Dane's photography
- Nvidia AI turns sketches into photorealistic landscapes in seconds
The Pragmatic Bookshelf published it's most important book, in my opinion, in 2017 with the first pytest book available from any publisher.
Topics:
- The Pragmatic Programmer, the book
- The Manifesto for Agile Software Development
- Agile methodologies and lightweight methods
- Some issues with "Agile" as it is now.
- The GROWS Method
- Pragmatic Bookshelf, the publishing company
- How Pragmatic Bookshelf is different, and what it's like to be an author with them.
- Reading and writing sci-fi novels, including Conglommora, Andy's novels.
- Playing music.
Special Guest: Andy Hunt.
]]>The Pragmatic Bookshelf published it's most important book, in my opinion, in 2017 with the first pytest book available from any publisher.
Topics:
- The Pragmatic Programmer, the book
- The Manifesto for Agile Software Development
- Agile methodologies and lightweight methods
- Some issues with "Agile" as it is now.
- The GROWS Method
- Pragmatic Bookshelf, the publishing company
- How Pragmatic Bookshelf is different, and what it's like to be an author with them.
- Reading and writing sci-fi novels, including Conglommora, Andy's novels.
- Playing music.
Special Guest: Andy Hunt.
]]>The Pragmatic Bookshelf published it's most important book, in my opinion, in 2017 with the first pytest book available from any publisher.
Topics:
- The Pragmatic Programmer, the book
- The Manifesto for Agile Software Development
- Agile methodologies and lightweight methods
- Some issues with "Agile" as it is now.
- The GROWS Method
- Pragmatic Bookshelf, the publishing company
- How Pragmatic Bookshelf is different, and what it's like to be an author with them.
- Reading and writing sci-fi novels, including Conglommora, Andy's novels.
- Playing music.
Special Guest: Andy Hunt.
]]>Then run the tests again to make sure your refactoring didn't break anything.
But what if it did break something?
Kent Beck has been recommending to commit your code to revision control after every green test run.
Oddmund Strømme suggested a symmetrical idea to go ahead and revert the code when a test fails.
Kent writes that he hated the idea, but had to try it.
Then wrote about it last September.
And now we have TCR, "(test && commit) || revert".
What's it feel like to actually do this?
Well, Thomas Deniffel has been using it since about a month after that article came out.
In this episode, we'll hear from Thomas about his experience with it.
It's a fascinating idea. Have a listen and let me know what you think.
Special Guest: Thomas Deniffel.
Links:
- test && commit || revert — Kent Beck's original article
- TCR: (test && commit || revert). How to use? Alternative to TDD? — Thomas Deniffel's article
- TCR Variants (test && commit || revert)
- TCR: A pulverizer for coding tasks — Another interesting opinion from someone else trying TCR - Jason Crawford
- (test && commit || revert) Questions Answered — Written after this interview.
Then run the tests again to make sure your refactoring didn't break anything.
But what if it did break something?
Kent Beck has been recommending to commit your code to revision control after every green test run.
Oddmund Strømme suggested a symmetrical idea to go ahead and revert the code when a test fails.
Kent writes that he hated the idea, but had to try it.
Then wrote about it last September.
And now we have TCR, "(test && commit) || revert".
What's it feel like to actually do this?
Well, Thomas Deniffel has been using it since about a month after that article came out.
In this episode, we'll hear from Thomas about his experience with it.
It's a fascinating idea. Have a listen and let me know what you think.
Special Guest: Thomas Deniffel.
Links:
- test && commit || revert — Kent Beck's original article
- TCR: (test && commit || revert). How to use? Alternative to TDD? — Thomas Deniffel's article
- TCR Variants (test && commit || revert)
- TCR: A pulverizer for coding tasks — Another interesting opinion from someone else trying TCR - Jason Crawford
- (test && commit || revert) Questions Answered — Written after this interview.
Then run the tests again to make sure your refactoring didn't break anything.
But what if it did break something?
Kent Beck has been recommending to commit your code to revision control after every green test run.
Oddmund Strømme suggested a symmetrical idea to go ahead and revert the code when a test fails.
Kent writes that he hated the idea, but had to try it.
Then wrote about it last September.
And now we have TCR, "(test && commit) || revert".
What's it feel like to actually do this?
Well, Thomas Deniffel has been using it since about a month after that article came out.
In this episode, we'll hear from Thomas about his experience with it.
It's a fascinating idea. Have a listen and let me know what you think.
Special Guest: Thomas Deniffel.
Links:
- test && commit || revert — Kent Beck's original article
- TCR: (test && commit || revert). How to use? Alternative to TDD? — Thomas Deniffel's article
- TCR Variants (test && commit || revert)
- TCR: A pulverizer for coding tasks — Another interesting opinion from someone else trying TCR - Jason Crawford
- (test && commit || revert) Questions Answered — Written after this interview.
They teach Python in a middle school in Florida, and talk about this experience on the podcast "Teaching Python".
I love that they include physical computing right from the start, and everything else they are doing.
It's a fun interview.
Special Guests: Kelly Paredes and Sean Tibor.
Links:
]]>They teach Python in a middle school in Florida, and talk about this experience on the podcast "Teaching Python".
I love that they include physical computing right from the start, and everything else they are doing.
It's a fun interview.
Special Guests: Kelly Paredes and Sean Tibor.
Links:
]]>They teach Python in a middle school in Florida, and talk about this experience on the podcast "Teaching Python".
I love that they include physical computing right from the start, and everything else they are doing.
It's a fun interview.
Special Guests: Kelly Paredes and Sean Tibor.
Links:
]]>Phil Burgess is the host of the podcast, and it was a lot of fun.
I think it turned out well, and I wanted to share it with you here, with Phil's permission, of course.
Special Guest: Phil Burgess.
Links:
]]>Phil Burgess is the host of the podcast, and it was a lot of fun.
I think it turned out well, and I wanted to share it with you here, with Phil's permission, of course.
Special Guest: Phil Burgess.
Links:
]]>Phil Burgess is the host of the podcast, and it was a lot of fun.
I think it turned out well, and I wanted to share it with you here, with Phil's permission, of course.
Special Guest: Phil Burgess.
Links:
]]>I've seen articles that say no, you should never have more than one assert.
I've also seen some test code made almost unreadable due to trying to avoid more than one assert per test.
Where did this recommendation even come from? What are the reasons?
What are the downsides to both perspectives?
That's what we're going to talk about today.
Links:
- Twitter survey about multiple asserts/checks — Are multiple asserts/checks ok in an automated test?
- Multiple Asserts Are OK - Bill Wake
- pytest-check: A pytest plugin that allows multiple failures per test.
I've seen articles that say no, you should never have more than one assert.
I've also seen some test code made almost unreadable due to trying to avoid more than one assert per test.
Where did this recommendation even come from? What are the reasons?
What are the downsides to both perspectives?
That's what we're going to talk about today.
Links:
- Twitter survey about multiple asserts/checks — Are multiple asserts/checks ok in an automated test?
- Multiple Asserts Are OK - Bill Wake
- pytest-check: A pytest plugin that allows multiple failures per test.
I've seen articles that say no, you should never have more than one assert.
I've also seen some test code made almost unreadable due to trying to avoid more than one assert per test.
Where did this recommendation even come from? What are the reasons?
What are the downsides to both perspectives?
That's what we're going to talk about today.
Links:
- Twitter survey about multiple asserts/checks — Are multiple asserts/checks ok in an automated test?
- Multiple Asserts Are OK - Bill Wake
- pytest-check: A pytest plugin that allows multiple failures per test.
By "get the most" I mean:
- the most fun
- the most value
- more career options
- probably more responsibility
- maybe even more money, that'd be cool
I want you to start (or continue) studying and practicing your skills.
But not just random practice, I've got a strategy to help you focus what to study.
Why am I talking about this now? Here's some background on how I re-learned how to have fun with code refactoring through code challenges.
I'm going to write up the whole list as a blog post, which I'll share first with my Patreon Supporters, second with my email list and slack channel and then as an actual post somewhere.
Links:
- practicing-programming - Steve Yegge — essay
- The Ultimate Code Kata - Jeff Atwood
- Teach Yourself Programming in Ten Years - Peter Norvig
- PyBites Code Challenges — Hone your Python Skills, in the browser
- CheckiO — JavaScript & Python challenges
- Exercism — code practice
- Codewars — Train with Programming Challenges/Kata
- Python Morsels — Challenges emailed to you once a week
- subreddit of code challenges
By "get the most" I mean:
- the most fun
- the most value
- more career options
- probably more responsibility
- maybe even more money, that'd be cool
I want you to start (or continue) studying and practicing your skills.
But not just random practice, I've got a strategy to help you focus what to study.
Why am I talking about this now? Here's some background on how I re-learned how to have fun with code refactoring through code challenges.
I'm going to write up the whole list as a blog post, which I'll share first with my Patreon Supporters, second with my email list and slack channel and then as an actual post somewhere.
Links:
- practicing-programming - Steve Yegge — essay
- The Ultimate Code Kata - Jeff Atwood
- Teach Yourself Programming in Ten Years - Peter Norvig
- PyBites Code Challenges — Hone your Python Skills, in the browser
- CheckiO — JavaScript & Python challenges
- Exercism — code practice
- Codewars — Train with Programming Challenges/Kata
- Python Morsels — Challenges emailed to you once a week
- subreddit of code challenges
By "get the most" I mean:
- the most fun
- the most value
- more career options
- probably more responsibility
- maybe even more money, that'd be cool
I want you to start (or continue) studying and practicing your skills.
But not just random practice, I've got a strategy to help you focus what to study.
Why am I talking about this now? Here's some background on how I re-learned how to have fun with code refactoring through code challenges.
I'm going to write up the whole list as a blog post, which I'll share first with my Patreon Supporters, second with my email list and slack channel and then as an actual post somewhere.
Links:
- practicing-programming - Steve Yegge — essay
- The Ultimate Code Kata - Jeff Atwood
- Teach Yourself Programming in Ten Years - Peter Norvig
- PyBites Code Challenges — Hone your Python Skills, in the browser
- CheckiO — JavaScript & Python challenges
- Exercism — code practice
- Codewars — Train with Programming Challenges/Kata
- Python Morsels — Challenges emailed to you once a week
- subreddit of code challenges
I see and I remember.
I do and I understand.
-- Confucius
Matt Harrison is an author and instructor of Python and Data Science. This episode focuses on his training company, MetaSnake, and corporate training.
Matt's written several books on Python, mostly self published. So of course we talk about that.
But the bulk of the conversation is about corporate training, with Brian playing the role of someone considering starting a corporate training role, and asking Matt, an experienced expert in training, how to start and where to go from there.
I think you'll learn a lot from this.
Special Guest: Matt Harrison.
Links:
- MetaSnake — Python Consultant and Training
- Illustrated Guide to Python 3 — A Complete Walkthrough of Beginning Python with Unique Illustrations Showing how Python Really Works
- Learning the Pandas Library — Python Tools for Data Munging, Analysis, and Visualization
- Beginning Python Programming — Learn Python in 7 Days
I see and I remember.
I do and I understand.
-- Confucius
Matt Harrison is an author and instructor of Python and Data Science. This episode focuses on his training company, MetaSnake, and corporate training.
Matt's written several books on Python, mostly self published. So of course we talk about that.
But the bulk of the conversation is about corporate training, with Brian playing the role of someone considering starting a corporate training role, and asking Matt, an experienced expert in training, how to start and where to go from there.
I think you'll learn a lot from this.
Special Guest: Matt Harrison.
Links:
- MetaSnake — Python Consultant and Training
- Illustrated Guide to Python 3 — A Complete Walkthrough of Beginning Python with Unique Illustrations Showing how Python Really Works
- Learning the Pandas Library — Python Tools for Data Munging, Analysis, and Visualization
- Beginning Python Programming — Learn Python in 7 Days
I see and I remember.
I do and I understand.
-- Confucius
Matt Harrison is an author and instructor of Python and Data Science. This episode focuses on his training company, MetaSnake, and corporate training.
Matt's written several books on Python, mostly self published. So of course we talk about that.
But the bulk of the conversation is about corporate training, with Brian playing the role of someone considering starting a corporate training role, and asking Matt, an experienced expert in training, how to start and where to go from there.
I think you'll learn a lot from this.
Special Guest: Matt Harrison.
Links:
- MetaSnake — Python Consultant and Training
- Illustrated Guide to Python 3 — A Complete Walkthrough of Beginning Python with Unique Illustrations Showing how Python Really Works
- Learning the Pandas Library — Python Tools for Data Munging, Analysis, and Visualization
- Beginning Python Programming — Learn Python in 7 Days
If your first encounter with pytest was reading an article in Linux Journal recently, that would be the writing of Reuven.
Reuven Lerner teaches Python.
This interview definitely falls into the category of talking with interesting people doing interesting things with Python.
We talk about how incorporating testing into teaching can add a level of clarity to the interaction and help people duirng the learning process.
I'm also fascinated by people who teach and train because it's a skill I'm trying to improve.
Special Guest: Reuven Lerner.
Links:
- Reuven's site
- Reuven's blog
- Reuven's online store
- Reuven's newsletter
- newsletter for trainers
- Weekly Python Exercise: Newbie edition — a 10% discount code for Test & Code listeners for the late January cohort.
If your first encounter with pytest was reading an article in Linux Journal recently, that would be the writing of Reuven.
Reuven Lerner teaches Python.
This interview definitely falls into the category of talking with interesting people doing interesting things with Python.
We talk about how incorporating testing into teaching can add a level of clarity to the interaction and help people duirng the learning process.
I'm also fascinated by people who teach and train because it's a skill I'm trying to improve.
Special Guest: Reuven Lerner.
Links:
- Reuven's site
- Reuven's blog
- Reuven's online store
- Reuven's newsletter
- newsletter for trainers
- Weekly Python Exercise: Newbie edition — a 10% discount code for Test & Code listeners for the late January cohort.
If your first encounter with pytest was reading an article in Linux Journal recently, that would be the writing of Reuven.
Reuven Lerner teaches Python.
This interview definitely falls into the category of talking with interesting people doing interesting things with Python.
We talk about how incorporating testing into teaching can add a level of clarity to the interaction and help people duirng the learning process.
I'm also fascinated by people who teach and train because it's a skill I'm trying to improve.
Special Guest: Reuven Lerner.
Links:
- Reuven's site
- Reuven's blog
- Reuven's online store
- Reuven's newsletter
- newsletter for trainers
- Weekly Python Exercise: Newbie edition — a 10% discount code for Test & Code listeners for the late January cohort.
Top 5 episodes:
- 2: Pytest vs Unittest vs Nose
- 33: Katharine Jarmul - Testing in Data Science
- 18: Testing in Startups and Hiring Software Engineers with Joe Stump
- 45: David Heinemeier Hansson - Software Development and Testing, TDD, and exploratory QA
- 27: Mahmoud Hashemi : unit, integration, and system testing
Honorable mention: 32: David Hussman - Agile vs Agility, Dude's Law, and more
This episode also went through lots of:
- what went well
- what was lacking
- what's next
Please listen and let me know where I should take this podcast.
]]>Top 5 episodes:
- 2: Pytest vs Unittest vs Nose
- 33: Katharine Jarmul - Testing in Data Science
- 18: Testing in Startups and Hiring Software Engineers with Joe Stump
- 45: David Heinemeier Hansson - Software Development and Testing, TDD, and exploratory QA
- 27: Mahmoud Hashemi : unit, integration, and system testing
Honorable mention: 32: David Hussman - Agile vs Agility, Dude's Law, and more
This episode also went through lots of:
- what went well
- what was lacking
- what's next
Please listen and let me know where I should take this podcast.
]]>Top 5 episodes:
- 2: Pytest vs Unittest vs Nose
- 33: Katharine Jarmul - Testing in Data Science
- 18: Testing in Startups and Hiring Software Engineers with Joe Stump
- 45: David Heinemeier Hansson - Software Development and Testing, TDD, and exploratory QA
- 27: Mahmoud Hashemi : unit, integration, and system testing
Honorable mention: 32: David Hussman - Agile vs Agility, Dude's Law, and more
This episode also went through lots of:
- what went well
- what was lacking
- what's next
Please listen and let me know where I should take this podcast.
]]>He's also a survivor of the 100DaysOfCode in Python Challenge.
We talk about the 100 days challenge, about learning Python, and about how cool it is to learn within a community.
Special Guest: Julian Sequeira.
Links:
]]>He's also a survivor of the 100DaysOfCode in Python Challenge.
We talk about the 100 days challenge, about learning Python, and about how cool it is to learn within a community.
Special Guest: Julian Sequeira.
Links:
]]>He's also a survivor of the 100DaysOfCode in Python Challenge.
We talk about the 100 days challenge, about learning Python, and about how cool it is to learn within a community.
Special Guest: Julian Sequeira.
Links:
]]>Thea is the creator of Nox, the co-chair of PyCascades 2019, the lead maintainer of urllib3, and a member of the Python Packaging Authority and Packaging Working Group.
Thea works on Google Cloud Platform's wonderful Developer Relations team where she works on API client libraries and community outreach.
All of that is definitely cool enough. But she is also building a synthesiser based on Sega Genesis chips. So of course, that's where we'll start the conversation.
Special Guest: Thea Flowers.
Links:
]]>Thea is the creator of Nox, the co-chair of PyCascades 2019, the lead maintainer of urllib3, and a member of the Python Packaging Authority and Packaging Working Group.
Thea works on Google Cloud Platform's wonderful Developer Relations team where she works on API client libraries and community outreach.
All of that is definitely cool enough. But she is also building a synthesiser based on Sega Genesis chips. So of course, that's where we'll start the conversation.
Special Guest: Thea Flowers.
Links:
]]>Thea is the creator of Nox, the co-chair of PyCascades 2019, the lead maintainer of urllib3, and a member of the Python Packaging Authority and Packaging Working Group.
Thea works on Google Cloud Platform's wonderful Developer Relations team where she works on API client libraries and community outreach.
All of that is definitely cool enough. But she is also building a synthesiser based on Sega Genesis chips. So of course, that's where we'll start the conversation.
Special Guest: Thea Flowers.
Links:
]]>It has a REST API that you want to use for testing.
Can you use Python for this testing even if the application is written in some other language? Of course.
Can you use pytest? duh. yes. what else?
What if you want to spin up docker instances, get your app running in that, and run your tests against that environment?
How would you use pytest to do that?
Well, there, I'm not exactly sure. But I know someone who does.
Dima Spivak is the Director of Engineering at StreamSets, and he and his team are doing just that.
He's also got some great advice on utilizing code reviews across teams for test code, and a whole lot more.
Special Guest: Dima Spivak.
Links:
]]>It has a REST API that you want to use for testing.
Can you use Python for this testing even if the application is written in some other language? Of course.
Can you use pytest? duh. yes. what else?
What if you want to spin up docker instances, get your app running in that, and run your tests against that environment?
How would you use pytest to do that?
Well, there, I'm not exactly sure. But I know someone who does.
Dima Spivak is the Director of Engineering at StreamSets, and he and his team are doing just that.
He's also got some great advice on utilizing code reviews across teams for test code, and a whole lot more.
Special Guest: Dima Spivak.
Links:
]]>It has a REST API that you want to use for testing.
Can you use Python for this testing even if the application is written in some other language? Of course.
Can you use pytest? duh. yes. what else?
What if you want to spin up docker instances, get your app running in that, and run your tests against that environment?
How would you use pytest to do that?
Well, there, I'm not exactly sure. But I know someone who does.
Dima Spivak is the Director of Engineering at StreamSets, and he and his team are doing just that.
He's also got some great advice on utilizing code reviews across teams for test code, and a whole lot more.
Special Guest: Dima Spivak.
Links:
]]>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 Huff
- Should you replace Hadoop with your laptop?
- Kaggle
- Project Jupyter
- Soviet Art Bot — A bot that finds socialist realism paintings and tweets them out
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 Huff
- Should you replace Hadoop with your laptop?
- Kaggle
- Project Jupyter
- Soviet Art Bot — A bot that finds socialist realism paintings and tweets them out
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 Huff
- Should you replace Hadoop with your laptop?
- Kaggle
- Project Jupyter
- Soviet Art Bot — A bot that finds socialist realism paintings and tweets them out
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 to expect the host or show to do before the recording.
- Where to record
- Sketching out some show topics with the host, maybe on a shared document.
- What to expect and do
- Right before the show
- During the conversation
- After the recording
- When it goes live (help promote it)
Special Guest: Michael Kennedy.
]]>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 to expect the host or show to do before the recording.
- Where to record
- Sketching out some show topics with the host, maybe on a shared document.
- What to expect and do
- Right before the show
- During the conversation
- After the recording
- When it goes live (help promote it)
Special Guest: Michael Kennedy.
]]>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 to expect the host or show to do before the recording.
- Where to record
- Sketching out some show topics with the host, maybe on a shared document.
- What to expect and do
- Right before the show
- During the conversation
- After the recording
- When it goes live (help promote it)
Special Guest: Michael Kennedy.
]]>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 Python
- Domain-specific language - Wikipedia
- awesome-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 Versioning
- episode 27: unit, integration, and system testing - Mahmoud Hashemi
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 Python
- Domain-specific language - Wikipedia
- awesome-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 Versioning
- episode 27: unit, integration, and system testing - Mahmoud Hashemi
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 Python
- Domain-specific language - Wikipedia
- awesome-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 Versioning
- episode 27: unit, integration, and system testing - Mahmoud Hashemi
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:
]]>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:
]]>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:
]]>We discuss a bit about each database: Redis, Neo4J, CouchDB, MongoDB, HBase, Postgres, and DynamoDB.
Special Guest: Luc Perkins.
Links:
]]>We discuss a bit about each database: Redis, Neo4J, CouchDB, MongoDB, HBase, Postgres, and DynamoDB.
Special Guest: Luc Perkins.
Links:
]]>We discuss a bit about each database: Redis, Neo4J, CouchDB, MongoDB, HBase, Postgres, and DynamoDB.
Special Guest: Luc Perkins.
Links:
]]>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:
]]>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:
]]>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:
]]>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:
]]>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:
]]>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:
]]>- 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 tests
- Microsoft article on flaky tests
- pytest-rerunfailures: a py.test plugin that re-runs failed tests up to -n times to eliminate flakey failures
- pytest-randomly: Pytest plugin to randomly order tests and control random.seed
- pytest-random-order: pytest plugin to randomise the order of tests with some control over the randomness
- math.isclose()
- numpy.isclose()
- pytest.approx() — approx
- Anthony's testing article on RealPython
- Ghost Inspector
- wily: A Python application for tracking, reporting on timing and complexity in tests
- 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 tests
- Microsoft article on flaky tests
- pytest-rerunfailures: a py.test plugin that re-runs failed tests up to -n times to eliminate flakey failures
- pytest-randomly: Pytest plugin to randomly order tests and control random.seed
- pytest-random-order: pytest plugin to randomise the order of tests with some control over the randomness
- math.isclose()
- numpy.isclose()
- pytest.approx() — approx
- Anthony's testing article on RealPython
- Ghost Inspector
- wily: A Python application for tracking, reporting on timing and complexity in tests
- 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 tests
- Microsoft article on flaky tests
- pytest-rerunfailures: a py.test plugin that re-runs failed tests up to -n times to eliminate flakey failures
- pytest-randomly: Pytest plugin to randomly order tests and control random.seed
- pytest-random-order: pytest plugin to randomise the order of tests with some control over the randomness
- math.isclose()
- numpy.isclose()
- pytest.approx() — approx
- Anthony's testing article on RealPython
- Ghost Inspector
- wily: A Python application for tracking, reporting on timing and complexity in tests
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 documentation
- tox recreate : "Have you turned it off and on again?" for tox
- "Hello world" of tox
- tox also has plugins
- talk by Bernát Gábor about a tox based workflow at EuroPython 2018
- adding a description to your environments
- detox - distributed tox
- devpi: private package index
- PyCharm plugin to easily set the project interpreter via context menu: PyVenvmanage
- power mode in atom
- Power Mode for PyCharm
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 documentation
- tox recreate : "Have you turned it off and on again?" for tox
- "Hello world" of tox
- tox also has plugins
- talk by Bernát Gábor about a tox based workflow at EuroPython 2018
- adding a description to your environments
- detox - distributed tox
- devpi: private package index
- PyCharm plugin to easily set the project interpreter via context menu: PyVenvmanage
- power mode in atom
- Power Mode for PyCharm
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 documentation
- tox recreate : "Have you turned it off and on again?" for tox
- "Hello world" of tox
- tox also has plugins
- talk by Bernát Gábor about a tox based workflow at EuroPython 2018
- adding a description to your environments
- detox - distributed tox
- devpi: private package index
- PyCharm plugin to easily set the project interpreter via context menu: PyVenvmanage
- power mode in atom
- Power Mode for PyCharm
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:
]]>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:
]]>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:
]]>- 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:
]]>- 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:
]]>- 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:
]]>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.
]]>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.
]]>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.
]]>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:
]]>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:
]]>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:
]]>Special Guest: Nina Zakharenko.
Links:
]]>Special Guest: Nina Zakharenko.
Links:
]]>Special Guest: Nina Zakharenko.
Links:
]]>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.
]]>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.
]]>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.
]]>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.
]]>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.
]]>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.
]]>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:
]]>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:
]]>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:
]]>Special Guest: Anthony Shaw.
Links:
]]>Special Guest: Anthony Shaw.
Links:
]]>Special Guest: Anthony Shaw.
Links:
]]>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 Ignored
- The Gently Mad – Life, business & entrepreneurship without the bullshit.
- avclark.com
- Justin Jacksons episodes on minimal podcasting | Build and Launch
- Dan Benjamin's Podcast Method podcast
- Python Bytes Podcast
- ATR2100 Mic
- Shure SM57 Mic
- Shure SM7B mic
- dbx 286s Microphone Preamp Processor
- Focusrite Scarlett 2i2 USB Audio Interface
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 Ignored
- The Gently Mad – Life, business & entrepreneurship without the bullshit.
- avclark.com
- Justin Jacksons episodes on minimal podcasting | Build and Launch
- Dan Benjamin's Podcast Method podcast
- Python Bytes Podcast
- ATR2100 Mic
- Shure SM57 Mic
- Shure SM7B mic
- dbx 286s Microphone Preamp Processor
- Focusrite Scarlett 2i2 USB Audio Interface
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 Ignored
- The Gently Mad – Life, business & entrepreneurship without the bullshit.
- avclark.com
- Justin Jacksons episodes on minimal podcasting | Build and Launch
- Dan Benjamin's Podcast Method podcast
- Python Bytes Podcast
- ATR2100 Mic
- Shure SM57 Mic
- Shure SM7B mic
- dbx 286s Microphone Preamp Processor
- Focusrite Scarlett 2i2 USB Audio Interface
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:
]]>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:
]]>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:
]]>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:
]]>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:
]]>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:
]]>We cover:
- My approach to testing existing systems.
- Put names to strategies so we can refer to them later.
- Explain the strategies in general terms and explain why they are useful.
- Discuss how these strategies are used in an example project. (The code is available on github).
Strategies covered today:
- Dog Fooding
- Exploratory Testing
- Tracer Bullet Tests
- Act Like A Customer (ALAC) Tests
- Manual Procedures
- Initial automated tests at 2 levels, API and UI.
We cover:
- My approach to testing existing systems.
- Put names to strategies so we can refer to them later.
- Explain the strategies in general terms and explain why they are useful.
- Discuss how these strategies are used in an example project. (The code is available on github).
Strategies covered today:
- Dog Fooding
- Exploratory Testing
- Tracer Bullet Tests
- Act Like A Customer (ALAC) Tests
- Manual Procedures
- Initial automated tests at 2 levels, API and UI.
We cover:
- My approach to testing existing systems.
- Put names to strategies so we can refer to them later.
- Explain the strategies in general terms and explain why they are useful.
- Discuss how these strategies are used in an example project. (The code is available on github).
Strategies covered today:
- Dog Fooding
- Exploratory Testing
- Tracer Bullet Tests
- Act Like A Customer (ALAC) Tests
- Manual Procedures
- Initial automated tests at 2 levels, API and UI.
She works on Basis, an image compressor, and has customers in games, video, mapping, and any application that has lots of image data.
Stephanie has also been encouraging experienced engineers to open up their twitter DMs to questions from anyone, to help mentor people not only in technical questions, but in career questions as well.
She also sets aside some time to mentor people through skype when written form just doesn't cut it.
That's the primary reason I have Stephanie on today, to talk about mentoring and open office hours.
But we also talk about
- Binomial
- image compression
- texture mapping
- the use of both manual and automated testing for complex systems
- sane work hours
- work life balance
- and how long hours have led her to the opinions she holds today
Special Guest: Stephanie Hurlburt.
Links:
- Binomial
- List of Engineers Willing to Mentor You — Stephanie Hurlburt
- Stephanie Hurlburt (@sehurlburt) | Twitter
- Slack - Python Testing / Test & Code — A super nice group of folks who are great at answering test related questions.
She works on Basis, an image compressor, and has customers in games, video, mapping, and any application that has lots of image data.
Stephanie has also been encouraging experienced engineers to open up their twitter DMs to questions from anyone, to help mentor people not only in technical questions, but in career questions as well.
She also sets aside some time to mentor people through skype when written form just doesn't cut it.
That's the primary reason I have Stephanie on today, to talk about mentoring and open office hours.
But we also talk about
- Binomial
- image compression
- texture mapping
- the use of both manual and automated testing for complex systems
- sane work hours
- work life balance
- and how long hours have led her to the opinions she holds today
Special Guest: Stephanie Hurlburt.
Links:
- Binomial
- List of Engineers Willing to Mentor You — Stephanie Hurlburt
- Stephanie Hurlburt (@sehurlburt) | Twitter
- Slack - Python Testing / Test & Code — A super nice group of folks who are great at answering test related questions.
She works on Basis, an image compressor, and has customers in games, video, mapping, and any application that has lots of image data.
Stephanie has also been encouraging experienced engineers to open up their twitter DMs to questions from anyone, to help mentor people not only in technical questions, but in career questions as well.
She also sets aside some time to mentor people through skype when written form just doesn't cut it.
That's the primary reason I have Stephanie on today, to talk about mentoring and open office hours.
But we also talk about
- Binomial
- image compression
- texture mapping
- the use of both manual and automated testing for complex systems
- sane work hours
- work life balance
- and how long hours have led her to the opinions she holds today
Special Guest: Stephanie Hurlburt.
Links:
- Binomial
- List of Engineers Willing to Mentor You — Stephanie Hurlburt
- Stephanie Hurlburt (@sehurlburt) | Twitter
- Slack - Python Testing / Test & Code — A super nice group of folks who are great at answering test related questions.
Of course, I'm a big fan of learning through reading books, such as upping your testing skills by reading Python Testing with pytest.
And then there are online learning systems and MOOCs.
At the other end of the spectrum is a full blown university degree.
One option kind of in the middle is continuing education programs available through some universities, such as University of Washington.
To discuss this option with me in more depth, we've got Andrew Hoover,
Senior Director, Program Strategy, University of Washington Continuum College
Special Guest: Andrew Hoover.
Links:
]]>Of course, I'm a big fan of learning through reading books, such as upping your testing skills by reading Python Testing with pytest.
And then there are online learning systems and MOOCs.
At the other end of the spectrum is a full blown university degree.
One option kind of in the middle is continuing education programs available through some universities, such as University of Washington.
To discuss this option with me in more depth, we've got Andrew Hoover,
Senior Director, Program Strategy, University of Washington Continuum College
Special Guest: Andrew Hoover.
Links:
]]>Of course, I'm a big fan of learning through reading books, such as upping your testing skills by reading Python Testing with pytest.
And then there are online learning systems and MOOCs.
At the other end of the spectrum is a full blown university degree.
One option kind of in the middle is continuing education programs available through some universities, such as University of Washington.
To discuss this option with me in more depth, we've got Andrew Hoover,
Senior Director, Program Strategy, University of Washington Continuum College
Special Guest: Andrew Hoover.
Links:
]]>- Why write tests first?
- How do you know what tests to write?
- What are the steps for test first?
- Isn't this just TDD?
- Functional Tests vs Unit Tests
Links:
- Test First Programming / Test First Development - Python Testing
- My reaction to "Is TDD Dead?" - Python Testing
- Episode 23: Lessons about testing and TDD from Kent Beck
- Talk Python, Episode #145 2017 Python Year in Review
- PyCon 2018 in Cleveland, Ohio | May 9-17
- Python Bytes Podcast
- Python Testing with pytest: Simple, Rapid, Effective, and Scalable: Brian Okken: 9781680502404: Amazon.com: Books
- Why write tests first?
- How do you know what tests to write?
- What are the steps for test first?
- Isn't this just TDD?
- Functional Tests vs Unit Tests
Links:
- Test First Programming / Test First Development - Python Testing
- My reaction to "Is TDD Dead?" - Python Testing
- Episode 23: Lessons about testing and TDD from Kent Beck
- Talk Python, Episode #145 2017 Python Year in Review
- PyCon 2018 in Cleveland, Ohio | May 9-17
- Python Bytes Podcast
- Python Testing with pytest: Simple, Rapid, Effective, and Scalable: Brian Okken: 9781680502404: Amazon.com: Books
- Why write tests first?
- How do you know what tests to write?
- What are the steps for test first?
- Isn't this just TDD?
- Functional Tests vs Unit Tests
Links:
- Test First Programming / Test First Development - Python Testing
- My reaction to "Is TDD Dead?" - Python Testing
- Episode 23: Lessons about testing and TDD from Kent Beck
- Talk Python, Episode #145 2017 Python Year in Review
- PyCon 2018 in Cleveland, Ohio | May 9-17
- Python Bytes Podcast
- Python Testing with pytest: Simple, Rapid, Effective, and Scalable: Brian Okken: 9781680502404: Amazon.com: Books
Some of the topics we discuss:
- experimentation vs testing
- testing pipelines and pipeline changes
- automating data validation
- property based testing
- schema validation and detecting schema changes
- using unit test techniques to test data pipeline stages
- testing nodes and transitions in DAGs
- testing expected and unexpected data
- missing data and non-signals
- corrupting a dataset with noise
- fuzz testing for both data pipelines and web APIs
- datafuzz
- hypothesis
- testing internal interfaces
- documenting and sharing domain expertise to build good reasonableness
- intermediary data and stages
- neural networks
- speaking at conferences
Special Guest: Katharine Jarmul.
Links:
- @kjam on Twitter — Data Magic and Computer Sorcery
- Kjamistan: Data Science
- datafuzz’s Python library — The goal of datafuzz is to give you the ability to test your data science code and models with BAD data.
- Hypothesis Python library — Hypothesis is a Python library for finding edge cases in your code you wouldn’t have thought to look for.
Some of the topics we discuss:
- experimentation vs testing
- testing pipelines and pipeline changes
- automating data validation
- property based testing
- schema validation and detecting schema changes
- using unit test techniques to test data pipeline stages
- testing nodes and transitions in DAGs
- testing expected and unexpected data
- missing data and non-signals
- corrupting a dataset with noise
- fuzz testing for both data pipelines and web APIs
- datafuzz
- hypothesis
- testing internal interfaces
- documenting and sharing domain expertise to build good reasonableness
- intermediary data and stages
- neural networks
- speaking at conferences
Special Guest: Katharine Jarmul.
Links:
- @kjam on Twitter — Data Magic and Computer Sorcery
- Kjamistan: Data Science
- datafuzz’s Python library — The goal of datafuzz is to give you the ability to test your data science code and models with BAD data.
- Hypothesis Python library — Hypothesis is a Python library for finding edge cases in your code you wouldn’t have thought to look for.
Some of the topics we discuss:
- experimentation vs testing
- testing pipelines and pipeline changes
- automating data validation
- property based testing
- schema validation and detecting schema changes
- using unit test techniques to test data pipeline stages
- testing nodes and transitions in DAGs
- testing expected and unexpected data
- missing data and non-signals
- corrupting a dataset with noise
- fuzz testing for both data pipelines and web APIs
- datafuzz
- hypothesis
- testing internal interfaces
- documenting and sharing domain expertise to build good reasonableness
- intermediary data and stages
- neural networks
- speaking at conferences
Special Guest: Katharine Jarmul.
Links:
- @kjam on Twitter — Data Magic and Computer Sorcery
- Kjamistan: Data Science
- datafuzz’s Python library — The goal of datafuzz is to give you the ability to test your data science code and models with BAD data.
- Hypothesis Python library — Hypothesis is a Python library for finding edge cases in your code you wouldn’t have thought to look for.
- How to build the wrong thing faster
- Agile vs Agility
- Product vs Process
- Where testing fits into software development practices.
- "Integration tests, there's a name that needs to be refactored desperately."
- Integration tests are "story tests". They tell the story of the product.
- XP and TDD and the relationship with tests
- To test for design, use microtests, xUnit style.
- User Advocy tests are often lacking, but are needed to learn about the product.
- "I just keep writing tests until I'm not scared anymore." - Kent Beck
- Dude's Law: Value = Why/How
- People often focus so much on the how that they forget about why they are doing something.
- Subcutaneous Tests
- "The hardest part of programming is thinking."
- Refactoring vs Repaving
- Agility means being able to quickly change direction
- During experimentation and learning, what matters isn't how much you got done, but how much you learn.
- "The best way to get automation is to make developers do manual tests."
Special Guest: David Hussman.
Links:
]]>- How to build the wrong thing faster
- Agile vs Agility
- Product vs Process
- Where testing fits into software development practices.
- "Integration tests, there's a name that needs to be refactored desperately."
- Integration tests are "story tests". They tell the story of the product.
- XP and TDD and the relationship with tests
- To test for design, use microtests, xUnit style.
- User Advocy tests are often lacking, but are needed to learn about the product.
- "I just keep writing tests until I'm not scared anymore." - Kent Beck
- Dude's Law: Value = Why/How
- People often focus so much on the how that they forget about why they are doing something.
- Subcutaneous Tests
- "The hardest part of programming is thinking."
- Refactoring vs Repaving
- Agility means being able to quickly change direction
- During experimentation and learning, what matters isn't how much you got done, but how much you learn.
- "The best way to get automation is to make developers do manual tests."
Special Guest: David Hussman.
Links:
]]>- How to build the wrong thing faster
- Agile vs Agility
- Product vs Process
- Where testing fits into software development practices.
- "Integration tests, there's a name that needs to be refactored desperately."
- Integration tests are "story tests". They tell the story of the product.
- XP and TDD and the relationship with tests
- To test for design, use microtests, xUnit style.
- User Advocy tests are often lacking, but are needed to learn about the product.
- "I just keep writing tests until I'm not scared anymore." - Kent Beck
- Dude's Law: Value = Why/How
- People often focus so much on the how that they forget about why they are doing something.
- Subcutaneous Tests
- "The hardest part of programming is thinking."
- Refactoring vs Repaving
- Agility means being able to quickly change direction
- During experimentation and learning, what matters isn't how much you got done, but how much you learn.
- "The best way to get automation is to make developers do manual tests."
Special Guest: David Hussman.
Links:
]]>Brian and Paul discuss testing practices such as the testing pyramid, TDD, unit testing, system testing, and balancing test effort.
- the Testing Pyramid
- the Testing Column
- TDD
- unit testing
- balancing unit with system tests, functional tests
- API testing
- subcutaneous testing
- customer facing tests
Special Guest: Paul Merrill.
<Links:
- Episode 34 - Software and Testing Models with Guest Host Brian Okken - Reflection As A Service — Cross posted to RaaS
- Subcutaneous Test — I use subcutaneous test to mean a test that operates just under the UI of an application.
- The Forgotten Layer of the Test Automation Pyramid — At the base of the test automation pyramid is unit testing.
- The Dreyfus model of skill acquisition — The Five-Stage Model of Adult Skill Acquisition
Brian and Paul discuss testing practices such as the testing pyramid, TDD, unit testing, system testing, and balancing test effort.
- the Testing Pyramid
- the Testing Column
- TDD
- unit testing
- balancing unit with system tests, functional tests
- API testing
- subcutaneous testing
- customer facing tests
Special Guest: Paul Merrill.
<Links:
- Episode 34 - Software and Testing Models with Guest Host Brian Okken - Reflection As A Service — Cross posted to RaaS
- Subcutaneous Test — I use subcutaneous test to mean a test that operates just under the UI of an application.
- The Forgotten Layer of the Test Automation Pyramid — At the base of the test automation pyramid is unit testing.
- The Dreyfus model of skill acquisition — The Five-Stage Model of Adult Skill Acquisition
Brian and Paul discuss testing practices such as the testing pyramid, TDD, unit testing, system testing, and balancing test effort.
- the Testing Pyramid
- the Testing Column
- TDD
- unit testing
- balancing unit with system tests, functional tests
- API testing
- subcutaneous testing
- customer facing tests
Special Guest: Paul Merrill.
<Links:
- Episode 34 - Software and Testing Models with Guest Host Brian Okken - Reflection As A Service — Cross posted to RaaS
- Subcutaneous Test — I use subcutaneous test to mean a test that operates just under the UI of an application.
- The Forgotten Layer of the Test Automation Pyramid — At the base of the test automation pyramid is unit testing.
- The Dreyfus model of skill acquisition — The Five-Stage Model of Adult Skill Acquisition
Topics include:
- How M. Scott Ford got into forming a company that works on legacy code.
- Technical debt
- Process debt
- Software testing
- The testing pyramid
- iterative development
- kanban
- readable code and readable test code
Special Guest: M. Scott Ford.
]]>Topics include:
- How M. Scott Ford got into forming a company that works on legacy code.
- Technical debt
- Process debt
- Software testing
- The testing pyramid
- iterative development
- kanban
- readable code and readable test code
Special Guest: M. Scott Ford.
]]>Topics include:
- How M. Scott Ford got into forming a company that works on legacy code.
- Technical debt
- Process debt
- Software testing
- The testing pyramid
- iterative development
- kanban
- readable code and readable test code
Special Guest: M. Scott Ford.
]]>QASymphony offers software testing and QA tools.
Special Guest: Josh Lieberman.
]]>QASymphony offers software testing and QA tools.
Special Guest: Josh Lieberman.
]]>QASymphony offers software testing and QA tools.
Special Guest: Josh Lieberman.
]]>One of the people making sure Netflix runs smoothly is Casey Rosenthall.
He is the manager for the Traffic, Intuition, and Chaos teams at Netflix.
He's got a great perspective on quality and large systems.
We talk about
- Chaos Engineering
- Experimentation vs Testing
- Testing Strategy
- Visualization of large amounts of data representing Steady State
Special Guest: Casey Rosenthal.
]]>One of the people making sure Netflix runs smoothly is Casey Rosenthall.
He is the manager for the Traffic, Intuition, and Chaos teams at Netflix.
He's got a great perspective on quality and large systems.
We talk about
- Chaos Engineering
- Experimentation vs Testing
- Testing Strategy
- Visualization of large amounts of data representing Steady State
Special Guest: Casey Rosenthal.
]]>One of the people making sure Netflix runs smoothly is Casey Rosenthall.
He is the manager for the Traffic, Intuition, and Chaos teams at Netflix.
He's got a great perspective on quality and large systems.
We talk about
- Chaos Engineering
- Experimentation vs Testing
- Testing Strategy
- Visualization of large amounts of data representing Steady State
Special Guest: Casey Rosenthal.
]]>- What is the difference between a unit test, an integration test, and a system test?
- TDD
- testing pyramid vs testing column
- the role of testing in software development
- web frameworks
- listen to wikipedia
- hatnote
- the world’s largest photo competition
- Enterprise Software with Python
Links:
- Mahmoud on twitter: @mhashemi
- Mahmoud on sedimental
- hatnote
- listen to wikipedia
- Montage, the web platform used to help judge the world’s largest photo competition
- clastic
- 10 Myths of Enterprise Python
- Enterprise Software with Python course
- Enterprise Software with Python blog post.
Special Guest: Mahmoud Hashemi.
]]>- What is the difference between a unit test, an integration test, and a system test?
- TDD
- testing pyramid vs testing column
- the role of testing in software development
- web frameworks
- listen to wikipedia
- hatnote
- the world’s largest photo competition
- Enterprise Software with Python
Links:
- Mahmoud on twitter: @mhashemi
- Mahmoud on sedimental
- hatnote
- listen to wikipedia
- Montage, the web platform used to help judge the world’s largest photo competition
- clastic
- 10 Myths of Enterprise Python
- Enterprise Software with Python course
- Enterprise Software with Python blog post.
Special Guest: Mahmoud Hashemi.
]]>- What is the difference between a unit test, an integration test, and a system test?
- TDD
- testing pyramid vs testing column
- the role of testing in software development
- web frameworks
- listen to wikipedia
- hatnote
- the world’s largest photo competition
- Enterprise Software with Python
Links:
- Mahmoud on twitter: @mhashemi
- Mahmoud on sedimental
- hatnote
- listen to wikipedia
- Montage, the web platform used to help judge the world’s largest photo competition
- clastic
- 10 Myths of Enterprise Python
- Enterprise Software with Python course
- Enterprise Software with Python blog post.
Special Guest: Mahmoud Hashemi.
]]>pyresttest
A question in the Test & Code Slack channel was raised about testing REST APIs. There were answers such as pytest + requests, of course, but there was also a mention of pyresttest, https://github.com/svanoort/pyresttest, which I hadn't heard of. I checked out the github repo, and was struck by how user friendly the user facing test definitions were. So I contacted the developer, Sam Van Oort, and asked him to come on the show and tell me about this tool and why he developed it.
Here's the "What is it?" section from the pyresttest README:
- A REST testing and API microbenchmarking tool
- Tests are defined in basic YAML or JSON config files, no code needed
- Minimal dependencies (pycurl, pyyaml, optionally future), making it easy to deploy on-server for smoketests/healthchecks
- Supports generate/extract/validate mechanisms to create full test scenarios
- Returns exit codes on failure, to slot into automated configuration management/orchestration tools (also supplies parseable logs)
- Logic is written and extensible in Python
Support
Special thanks to my wonderful Patreon supporters and those who have supported the show by purchasing Python Testing with unittest, nose, pytest
]]>pyresttest
A question in the Test & Code Slack channel was raised about testing REST APIs. There were answers such as pytest + requests, of course, but there was also a mention of pyresttest, https://github.com/svanoort/pyresttest, which I hadn't heard of. I checked out the github repo, and was struck by how user friendly the user facing test definitions were. So I contacted the developer, Sam Van Oort, and asked him to come on the show and tell me about this tool and why he developed it.
Here's the "What is it?" section from the pyresttest README:
- A REST testing and API microbenchmarking tool
- Tests are defined in basic YAML or JSON config files, no code needed
- Minimal dependencies (pycurl, pyyaml, optionally future), making it easy to deploy on-server for smoketests/healthchecks
- Supports generate/extract/validate mechanisms to create full test scenarios
- Returns exit codes on failure, to slot into automated configuration management/orchestration tools (also supplies parseable logs)
- Logic is written and extensible in Python
Support
Special thanks to my wonderful Patreon supporters and those who have supported the show by purchasing Python Testing with unittest, nose, pytest
]]>pyresttest
A question in the Test & Code Slack channel was raised about testing REST APIs. There were answers such as pytest + requests, of course, but there was also a mention of pyresttest, https://github.com/svanoort/pyresttest, which I hadn't heard of. I checked out the github repo, and was struck by how user friendly the user facing test definitions were. So I contacted the developer, Sam Van Oort, and asked him to come on the show and tell me about this tool and why he developed it.
Here's the "What is it?" section from the pyresttest README:
- A REST testing and API microbenchmarking tool
- Tests are defined in basic YAML or JSON config files, no code needed
- Minimal dependencies (pycurl, pyyaml, optionally future), making it easy to deploy on-server for smoketests/healthchecks
- Supports generate/extract/validate mechanisms to create full test scenarios
- Returns exit codes on failure, to slot into automated configuration management/orchestration tools (also supplies parseable logs)
- Logic is written and extensible in Python
Support
Special thanks to my wonderful Patreon supporters and those who have supported the show by purchasing Python Testing with unittest, nose, pytest
]]>d
We Cover:
Also:
- fixtures
- xfail
- CI and xfail and html reports
- CI and capturing
- pytest code sprint
- working remotely for Mozilla
d
We Cover:
Also:
- fixtures
- xfail
- CI and xfail and html reports
- CI and capturing
- pytest code sprint
- working remotely for Mozilla
d
We Cover:
Also:
- fixtures
- xfail
- CI and xfail and html reports
- CI and capturing
- pytest code sprint
- working remotely for Mozilla
In this episode, I interview Raphael Aurich (@hackebrot), a core contributor to both pytest and cookiecutter. We discuss how Raphael got involved with both projects, his involvement in cookiecutter, pytest, "adopt pytest month", the pytest code sprint, and of course some of the cool new features in pytest 3.
Links:
- pytest - http://doc.pytest.org
- cookie cutter - https://github.com/audreyr/cookiecutter
- cookiecutter-pytest-plugin - https://github.com/pytest-dev/cookiecutter-pytest-plugin
In this episode, I interview Raphael Aurich (@hackebrot), a core contributor to both pytest and cookiecutter. We discuss how Raphael got involved with both projects, his involvement in cookiecutter, pytest, "adopt pytest month", the pytest code sprint, and of course some of the cool new features in pytest 3.
Links:
- pytest - http://doc.pytest.org
- cookie cutter - https://github.com/audreyr/cookiecutter
- cookiecutter-pytest-plugin - https://github.com/pytest-dev/cookiecutter-pytest-plugin
In this episode, I interview Raphael Aurich (@hackebrot), a core contributor to both pytest and cookiecutter. We discuss how Raphael got involved with both projects, his involvement in cookiecutter, pytest, "adopt pytest month", the pytest code sprint, and of course some of the cool new features in pytest 3.
Links:
- pytest - http://doc.pytest.org
- cookie cutter - https://github.com/audreyr/cookiecutter
- cookiecutter-pytest-plugin - https://github.com/pytest-dev/cookiecutter-pytest-plugin
I first ran across writings from Kent Beck as started exploring Extreme Programming in the early 2000's.
Although I don't agree with all of the views he's expressed in his long and verbose career, I respect him as one of the best sources of information about software development, engineering practices, and software testing.
Along with Test First Programming and Test Driven Development, Kent started an automated test framework that turned into jUnit. jUnit and it's model of setup and teardown wrapping test functions, as well base test class driven test frameworks became what we know of as xUnit style frameworks now, which includes Python's unittest.
He discussed this history and a lot more on episode 122 of Software Engineering Radio. The episode is titled "The History of JUnit and the Future of Testing with Kent Beck", and is from Sept 26, 2010.
I urge you to download it and listen to the whole thing. It's a great interview, still relevant, and applicable to testing in any language, including Python.
What I've done in this podcast is take a handful of clips from the interview (with permission from IEEE and SERadio), and discuss the clips and my opinions a bit.
The lessons are:
- You're tests should tell a story.
- Be careful of DRY, inheritance, and other software development practices that might get in the way of keeping your tests easy to understand.
- All test should help differentiate good programs from bad programs and not be redundant.
- Test at multiple levels and multiple scales where it makes sense.
- Differentiating between TDD, BDD, ATDD, etc. isn't as important as testing your software to learn about it. Who cares what you call it.
I first ran across writings from Kent Beck as started exploring Extreme Programming in the early 2000's.
Although I don't agree with all of the views he's expressed in his long and verbose career, I respect him as one of the best sources of information about software development, engineering practices, and software testing.
Along with Test First Programming and Test Driven Development, Kent started an automated test framework that turned into jUnit. jUnit and it's model of setup and teardown wrapping test functions, as well base test class driven test frameworks became what we know of as xUnit style frameworks now, which includes Python's unittest.
He discussed this history and a lot more on episode 122 of Software Engineering Radio. The episode is titled "The History of JUnit and the Future of Testing with Kent Beck", and is from Sept 26, 2010.
I urge you to download it and listen to the whole thing. It's a great interview, still relevant, and applicable to testing in any language, including Python.
What I've done in this podcast is take a handful of clips from the interview (with permission from IEEE and SERadio), and discuss the clips and my opinions a bit.
The lessons are:
- You're tests should tell a story.
- Be careful of DRY, inheritance, and other software development practices that might get in the way of keeping your tests easy to understand.
- All test should help differentiate good programs from bad programs and not be redundant.
- Test at multiple levels and multiple scales where it makes sense.
- Differentiating between TDD, BDD, ATDD, etc. isn't as important as testing your software to learn about it. Who cares what you call it.
I first ran across writings from Kent Beck as started exploring Extreme Programming in the early 2000's.
Although I don't agree with all of the views he's expressed in his long and verbose career, I respect him as one of the best sources of information about software development, engineering practices, and software testing.
Along with Test First Programming and Test Driven Development, Kent started an automated test framework that turned into jUnit. jUnit and it's model of setup and teardown wrapping test functions, as well base test class driven test frameworks became what we know of as xUnit style frameworks now, which includes Python's unittest.
He discussed this history and a lot more on episode 122 of Software Engineering Radio. The episode is titled "The History of JUnit and the Future of Testing with Kent Beck", and is from Sept 26, 2010.
I urge you to download it and listen to the whole thing. It's a great interview, still relevant, and applicable to testing in any language, including Python.
What I've done in this podcast is take a handful of clips from the interview (with permission from IEEE and SERadio), and discuss the clips and my opinions a bit.
The lessons are:
- You're tests should tell a story.
- Be careful of DRY, inheritance, and other software development practices that might get in the way of keeping your tests easy to understand.
- All test should help differentiate good programs from bad programs and not be redundant.
- Test at multiple levels and multiple scales where it makes sense.
- Differentiating between TDD, BDD, ATDD, etc. isn't as important as testing your software to learn about it. Who cares what you call it.
This episode looks at the differences between manual and automated tests and presents two strategies for converting manual to automated.
]]>This episode looks at the differences between manual and automated tests and presents two strategies for converting manual to automated.
]]>This episode looks at the differences between manual and automated tests and presents two strategies for converting manual to automated.
]]>I think it's a great idea.
Covered in this episode:
- Test Fixtures
- Subcutaneous Testing
- End to End Testing (System Testing)
I also discuss:
- A book rewrite
- Progress on transcripts
- A story from the slack channel
I think it's a great idea.
Covered in this episode:
- Test Fixtures
- Subcutaneous Testing
- End to End Testing (System Testing)
I also discuss:
- A book rewrite
- Progress on transcripts
- A story from the slack channel
I think it's a great idea.
Covered in this episode:
- Test Fixtures
- Subcutaneous Testing
- End to End Testing (System Testing)
I also discuss:
- A book rewrite
- Progress on transcripts
- A story from the slack channel
- Episodes of his show having to do with testing.
- His transition from employee to podcast host and online training entrepreneur.
- His Python training courses.
- The Pyramid Web framework.
Courses by Michael
- Explore Python Jumpstart by Building 10 Apps
- Explore Write Pythonic Code Like a Seasoned Developer
- Python for Entrepreneurs
Testing related podcast Episodes from Talk Python To Me:
]]>- Episodes of his show having to do with testing.
- His transition from employee to podcast host and online training entrepreneur.
- His Python training courses.
- The Pyramid Web framework.
Courses by Michael
- Explore Python Jumpstart by Building 10 Apps
- Explore Write Pythonic Code Like a Seasoned Developer
- Python for Entrepreneurs
Testing related podcast Episodes from Talk Python To Me:
]]>- Episodes of his show having to do with testing.
- His transition from employee to podcast host and online training entrepreneur.
- His Python training courses.
- The Pyramid Web framework.
Courses by Michael
- Explore Python Jumpstart by Building 10 Apps
- Explore Write Pythonic Code Like a Seasoned Developer
- Python for Entrepreneurs
Testing related podcast Episodes from Talk Python To Me:
]]>Some of the topics covered
- How did Robert become the maintainer of unittest?
- unittest2 as a rolling backport of unittest
- test and class parametrization with subtest and testscenarios
- Which extension to unittest most closely resembles Pytest fixtures?
- Comparing Pytest and unittest
- Will unittest ever get assert rewriting?
- Future changes to unittest
I've been re-studying unittest recently and I mostly wanted to ask Robert a bunch of clarifying questions.
This is an intermediate to advanced discussion of unittest.
Many great features of unittest go by quickly in this talk.
Please let me know if there's something you'd like me to cover in more depth as a blog post or a future episode.
Links
]]>Some of the topics covered
- How did Robert become the maintainer of unittest?
- unittest2 as a rolling backport of unittest
- test and class parametrization with subtest and testscenarios
- Which extension to unittest most closely resembles Pytest fixtures?
- Comparing Pytest and unittest
- Will unittest ever get assert rewriting?
- Future changes to unittest
I've been re-studying unittest recently and I mostly wanted to ask Robert a bunch of clarifying questions.
This is an intermediate to advanced discussion of unittest.
Many great features of unittest go by quickly in this talk.
Please let me know if there's something you'd like me to cover in more depth as a blog post or a future episode.
Links
]]>Some of the topics covered
- How did Robert become the maintainer of unittest?
- unittest2 as a rolling backport of unittest
- test and class parametrization with subtest and testscenarios
- Which extension to unittest most closely resembles Pytest fixtures?
- Comparing Pytest and unittest
- Will unittest ever get assert rewriting?
- Future changes to unittest
I've been re-studying unittest recently and I mostly wanted to ask Robert a bunch of clarifying questions.
This is an intermediate to advanced discussion of unittest.
Many great features of unittest go by quickly in this talk.
Please let me know if there's something you'd like me to cover in more depth as a blog post or a future episode.
Links
]]>Joe has spent his career in startups.
He's also been involved with hiring and talent acquisition for several startups.
We talk about testing, continuous integration, code reviews, deployment, tolerance to defects, and how some of those differ between large companies and small companies and startups.
Then we get into hiring. Specifically, finding and evaluating good engineers, and then getting them to be interested in working for you.
If you ever want to grow your team size, you need to listen to this.
Joe has spent his career in startups.
He's also been involved with hiring and talent acquisition for several startups.
We talk about testing, continuous integration, code reviews, deployment, tolerance to defects, and how some of those differ between large companies and small companies and startups.
Then we get into hiring. Specifically, finding and evaluating good engineers, and then getting them to be interested in working for you.
If you ever want to grow your team size, you need to listen to this.
Joe has spent his career in startups.
He's also been involved with hiring and talent acquisition for several startups.
We talk about testing, continuous integration, code reviews, deployment, tolerance to defects, and how some of those differ between large companies and small companies and startups.
Then we get into hiring. Specifically, finding and evaluating good engineers, and then getting them to be interested in working for you.
If you ever want to grow your team size, you need to listen to this.
Links and things we talked about:
]]>Links and things we talked about:
]]>Links and things we talked about:
]]>I'm changing the name from the "Python Test Podcast" to "Test & Code".
I just want to discuss the reasons behind this change, and take a peek at what's coming up in the future for this podcast.
Links
]]>I'm changing the name from the "Python Test Podcast" to "Test & Code".
I just want to discuss the reasons behind this change, and take a peek at what's coming up in the future for this podcast.
Links
]]>I'm changing the name from the "Python Test Podcast" to "Test & Code".
I just want to discuss the reasons behind this change, and take a peek at what's coming up in the future for this podcast.
Links
]]>This is a quick intro to the concepts of Lean Software Development.
I'm starting a journey of trying to figure out how to apply lean principles to software development in the context of 2016/2017.
Links
- Lean Software Development book by Mary & Tom Poppendieck
- wikipedia entry for Lean Software Development
- Patreon supporters of the show
- Talk Python to Me Podcast
- Python Jumpstart by Building 10 Apps - video course
- pytest sprint
- pytest.org
- pytest/tox indiegogo campaign
This is a quick intro to the concepts of Lean Software Development.
I'm starting a journey of trying to figure out how to apply lean principles to software development in the context of 2016/2017.
Links
- Lean Software Development book by Mary & Tom Poppendieck
- wikipedia entry for Lean Software Development
- Patreon supporters of the show
- Talk Python to Me Podcast
- Python Jumpstart by Building 10 Apps - video course
- pytest sprint
- pytest.org
- pytest/tox indiegogo campaign
This is a quick intro to the concepts of Lean Software Development.
I'm starting a journey of trying to figure out how to apply lean principles to software development in the context of 2016/2017.
Links
- Lean Software Development book by Mary & Tom Poppendieck
- wikipedia entry for Lean Software Development
- Patreon supporters of the show
- Talk Python to Me Podcast
- Python Jumpstart by Building 10 Apps - video course
- pytest sprint
- pytest.org
- pytest/tox indiegogo campaign
Josh is a co-founder and Chief Post-It Officer at Travis CI.
Topics
- What is Continuous Integration, CI
- What is Travis CI
- Some history of the company
- travis-ci.org vs travis-ci.com and merging the two
- Enterprise and the importance of security
- Feature questions
- Travis vs Jenkins
- Travis notification through Slack
- Reporting history of Travis results
- Dealing with pytest results status other than pass/fail
- Capturing std out and stderr logging from tests
- Build artifacts
- Tox and Travis
- Using Selenium
- What does a Chief Post-It Officer do
- Differentiation between Travis and other CI options
- Using Slack to keep remote teams communicating well
- Travis team
- Funding open source projects
- Travis Foundation
- Rails Girls Summer of Code
- Open source grants
- Mustaches and beards
- Shite shirts
- New Zealand
- What does Team Periwinkle do
Links
]]>Josh is a co-founder and Chief Post-It Officer at Travis CI.
Topics
- What is Continuous Integration, CI
- What is Travis CI
- Some history of the company
- travis-ci.org vs travis-ci.com and merging the two
- Enterprise and the importance of security
- Feature questions
- Travis vs Jenkins
- Travis notification through Slack
- Reporting history of Travis results
- Dealing with pytest results status other than pass/fail
- Capturing std out and stderr logging from tests
- Build artifacts
- Tox and Travis
- Using Selenium
- What does a Chief Post-It Officer do
- Differentiation between Travis and other CI options
- Using Slack to keep remote teams communicating well
- Travis team
- Funding open source projects
- Travis Foundation
- Rails Girls Summer of Code
- Open source grants
- Mustaches and beards
- Shite shirts
- New Zealand
- What does Team Periwinkle do
Links
]]>Josh is a co-founder and Chief Post-It Officer at Travis CI.
Topics
- What is Continuous Integration, CI
- What is Travis CI
- Some history of the company
- travis-ci.org vs travis-ci.com and merging the two
- Enterprise and the importance of security
- Feature questions
- Travis vs Jenkins
- Travis notification through Slack
- Reporting history of Travis results
- Dealing with pytest results status other than pass/fail
- Capturing std out and stderr logging from tests
- Build artifacts
- Tox and Travis
- Using Selenium
- What does a Chief Post-It Officer do
- Differentiation between Travis and other CI options
- Using Slack to keep remote teams communicating well
- Travis team
- Funding open source projects
- Travis Foundation
- Rails Girls Summer of Code
- Open source grants
- Mustaches and beards
- Shite shirts
- New Zealand
- What does Team Periwinkle do
Links
]]>Interview with Ian Cordasco (@sigmavirus24)
Topics:
- Betamax - python library for replaying requests interactions for use in testing.
- requests
- github3.py
- Pycon 2015 talk: Ian Cordasco - Cutting Off the Internet: Testing Applications that Use Requests - PyCon 2015
- Pytest and using Betamax with pytest fixtures
- The utility (or uselessness) of teaching programming with Java (My own rant mainly)
- Rackspace and Ian’s role at Rackspace and OpenStack
- Python Code Quality Authority: flake8, pep8, mccabe, pylint, astroid, …
- Static code analysis and what to use which tool when.
- Raymond Hettinger - Beyond PEP 8 -- Best practices for beautiful intelligible code - PyCon 2015
Links:
- Testing Python-Requests with Betamax
- Cutting Off the Internet: Testing Applications that Use Requests - PyCon 2015
- github3.py
- requests
- Rackspace
- Openstack
- Python Code Quality Authority and documentation
- GitLab
- Raymond Hettinger - Beyond PEP 8 -- Best practices for beautiful intelligible code - PyCon 2015
Other Betamax resources:
]]>Interview with Ian Cordasco (@sigmavirus24)
Topics:
- Betamax - python library for replaying requests interactions for use in testing.
- requests
- github3.py
- Pycon 2015 talk: Ian Cordasco - Cutting Off the Internet: Testing Applications that Use Requests - PyCon 2015
- Pytest and using Betamax with pytest fixtures
- The utility (or uselessness) of teaching programming with Java (My own rant mainly)
- Rackspace and Ian’s role at Rackspace and OpenStack
- Python Code Quality Authority: flake8, pep8, mccabe, pylint, astroid, …
- Static code analysis and what to use which tool when.
- Raymond Hettinger - Beyond PEP 8 -- Best practices for beautiful intelligible code - PyCon 2015
Links:
- Testing Python-Requests with Betamax
- Cutting Off the Internet: Testing Applications that Use Requests - PyCon 2015
- github3.py
- requests
- Rackspace
- Openstack
- Python Code Quality Authority and documentation
- GitLab
- Raymond Hettinger - Beyond PEP 8 -- Best practices for beautiful intelligible code - PyCon 2015
Other Betamax resources:
]]>Interview with Ian Cordasco (@sigmavirus24)
Topics:
- Betamax - python library for replaying requests interactions for use in testing.
- requests
- github3.py
- Pycon 2015 talk: Ian Cordasco - Cutting Off the Internet: Testing Applications that Use Requests - PyCon 2015
- Pytest and using Betamax with pytest fixtures
- The utility (or uselessness) of teaching programming with Java (My own rant mainly)
- Rackspace and Ian’s role at Rackspace and OpenStack
- Python Code Quality Authority: flake8, pep8, mccabe, pylint, astroid, …
- Static code analysis and what to use which tool when.
- Raymond Hettinger - Beyond PEP 8 -- Best practices for beautiful intelligible code - PyCon 2015
Links:
- Testing Python-Requests with Betamax
- Cutting Off the Internet: Testing Applications that Use Requests - PyCon 2015
- github3.py
- requests
- Rackspace
- Openstack
- Python Code Quality Authority and documentation
- GitLab
- Raymond Hettinger - Beyond PEP 8 -- Best practices for beautiful intelligible code - PyCon 2015
Other Betamax resources:
]]>I know that coverage.py is very important to a lot of people to understand how much of their code is being covered by their test suites.
Since I'm far from an expert on coverage, I asked Ned to discuss it on the show.
I'm also quite a fan of Ned's 2014 PyCon talk "Getting Started Testing", so I definitely asked him about that.
We also discuss edX, Python user groups, PyCon talks, and more.
Some of what's covered (pun intended) in this episode:
- coverage.py
- types of coverage
- Line coverage
- branch coverage
- Behavior coverage
- Data coverage
- How Ned became the owner of coverage.py
- Running tests from coverage.py vs running coverage from test runner.
- types of coverage
- edX
- what is it
- what Ned's role is
- Ned's blog
- Ned's PyCon 2014 talk "Getting Started Testing"
- Teaching testing and the difficulty of the classes being part of unittest
- fixtures package
- some of the difficulties of teaching unittest because of it's class based system.
- the history of classes in unittest coming from java's jUnit implementation
- Boston's Python Group
- PyCon in Portland
- Ned to do a talk here "Machete mode debugging".
- Practicing PyCon talks at local group meetings.
- At the very least, practice it in front of a live audience.
Links:
- Ned Batchelder
- Coverage
- Coverage documentation
- django-nose
- pytest-django
- edX
- open edX
- Boston Python User Group
- Portland Python User Group - I need to go to these
- PyCon 2016 - Planning on attending, it's in Portland. Yay!
- Getting Started Testing - Ned's 2014 Pycon talk
Special Guest: Ned Batchelder.
]]>I know that coverage.py is very important to a lot of people to understand how much of their code is being covered by their test suites.
Since I'm far from an expert on coverage, I asked Ned to discuss it on the show.
I'm also quite a fan of Ned's 2014 PyCon talk "Getting Started Testing", so I definitely asked him about that.
We also discuss edX, Python user groups, PyCon talks, and more.
Some of what's covered (pun intended) in this episode:
- coverage.py
- types of coverage
- Line coverage
- branch coverage
- Behavior coverage
- Data coverage
- How Ned became the owner of coverage.py
- Running tests from coverage.py vs running coverage from test runner.
- types of coverage
- edX
- what is it
- what Ned's role is
- Ned's blog
- Ned's PyCon 2014 talk "Getting Started Testing"
- Teaching testing and the difficulty of the classes being part of unittest
- fixtures package
- some of the difficulties of teaching unittest because of it's class based system.
- the history of classes in unittest coming from java's jUnit implementation
- Boston's Python Group
- PyCon in Portland
- Ned to do a talk here "Machete mode debugging".
- Practicing PyCon talks at local group meetings.
- At the very least, practice it in front of a live audience.
Links:
- Ned Batchelder
- Coverage
- Coverage documentation
- django-nose
- pytest-django
- edX
- open edX
- Boston Python User Group
- Portland Python User Group - I need to go to these
- PyCon 2016 - Planning on attending, it's in Portland. Yay!
- Getting Started Testing - Ned's 2014 Pycon talk
Special Guest: Ned Batchelder.
]]>I know that coverage.py is very important to a lot of people to understand how much of their code is being covered by their test suites.
Since I'm far from an expert on coverage, I asked Ned to discuss it on the show.
I'm also quite a fan of Ned's 2014 PyCon talk "Getting Started Testing", so I definitely asked him about that.
We also discuss edX, Python user groups, PyCon talks, and more.
Some of what's covered (pun intended) in this episode:
- coverage.py
- types of coverage
- Line coverage
- branch coverage
- Behavior coverage
- Data coverage
- How Ned became the owner of coverage.py
- Running tests from coverage.py vs running coverage from test runner.
- types of coverage
- edX
- what is it
- what Ned's role is
- Ned's blog
- Ned's PyCon 2014 talk "Getting Started Testing"
- Teaching testing and the difficulty of the classes being part of unittest
- fixtures package
- some of the difficulties of teaching unittest because of it's class based system.
- the history of classes in unittest coming from java's jUnit implementation
- Boston's Python Group
- PyCon in Portland
- Ned to do a talk here "Machete mode debugging".
- Practicing PyCon talks at local group meetings.
- At the very least, practice it in front of a live audience.
Links:
- Ned Batchelder
- Coverage
- Coverage documentation
- django-nose
- pytest-django
- edX
- open edX
- Boston Python User Group
- Portland Python User Group - I need to go to these
- PyCon 2016 - Planning on attending, it's in Portland. Yay!
- Getting Started Testing - Ned's 2014 Pycon talk
Special Guest: Ned Batchelder.
]]>The job of the test framework to tell developers how and why their tests failed is a difficult job.
In this episode I talk about assert helper functions and the 3 methods pytest uses to get around having users need to use assert helper functions.
The job of the test framework to tell developers how and why their tests failed is a difficult job.
In this episode I talk about assert helper functions and the 3 methods pytest uses to get around having users need to use assert helper functions.
The job of the test framework to tell developers how and why their tests failed is a difficult job.
In this episode I talk about assert helper functions and the 3 methods pytest uses to get around having users need to use assert helper functions.
It doesn’t matter if you are using pytest, unittest, nose, or something completely different, this episode will help you write better tests.
- The Given-When-Then structure for test method/function development.
- How and why to utilize fixtures for your given or precondition code.
- Similarities with other structure discriptions.
- Setup-Test-Teardown
- Setup-Excercise-Verify-Teardown.
- Arrange-Act-Assert
- Preconditions-Trigger-Postconditions.
- Benefits
- Communicate the purpose of your test more clearly
- Focus your thinking while writing the test
- Make test writing faster
- Make it easier to re-use parts of your test
- Highlight the assumptions you are making about the test preconditions
- Highlight what outcomes you are expecting and testing against.
Links discussed in the show:
]]>It doesn’t matter if you are using pytest, unittest, nose, or something completely different, this episode will help you write better tests.
- The Given-When-Then structure for test method/function development.
- How and why to utilize fixtures for your given or precondition code.
- Similarities with other structure discriptions.
- Setup-Test-Teardown
- Setup-Excercise-Verify-Teardown.
- Arrange-Act-Assert
- Preconditions-Trigger-Postconditions.
- Benefits
- Communicate the purpose of your test more clearly
- Focus your thinking while writing the test
- Make test writing faster
- Make it easier to re-use parts of your test
- Highlight the assumptions you are making about the test preconditions
- Highlight what outcomes you are expecting and testing against.
Links discussed in the show:
]]>It doesn’t matter if you are using pytest, unittest, nose, or something completely different, this episode will help you write better tests.
- The Given-When-Then structure for test method/function development.
- How and why to utilize fixtures for your given or precondition code.
- Similarities with other structure discriptions.
- Setup-Test-Teardown
- Setup-Excercise-Verify-Teardown.
- Arrange-Act-Assert
- Preconditions-Trigger-Postconditions.
- Benefits
- Communicate the purpose of your test more clearly
- Focus your thinking while writing the test
- Make test writing faster
- Make it easier to re-use parts of your test
- Highlight the assumptions you are making about the test preconditions
- Highlight what outcomes you are expecting and testing against.
Links discussed in the show:
]]>Update: Comment from Harry Percival on 19-Jan-2014
I might have been a bit down on unit tests vs functional tests in that "unit tests never fail comment".
Not true at all, particularly as we've just been thru upgrading django on our core system, and the unit tests really saved our bacon on that one...
Links
- Test-Driven Development with Python
- Obey the Testing Goat - Harry's site dedicated to the book and related posts.
- Python Testing with unittest, nose, pytest
- Gary Bernhardt's talk, Boundaries talk including a discussion of "Functional Core, Imperative Shell".
- Video of Boundaries talk on youtube
Update: Comment from Harry Percival on 19-Jan-2014
I might have been a bit down on unit tests vs functional tests in that "unit tests never fail comment".
Not true at all, particularly as we've just been thru upgrading django on our core system, and the unit tests really saved our bacon on that one...
Links
- Test-Driven Development with Python
- Obey the Testing Goat - Harry's site dedicated to the book and related posts.
- Python Testing with unittest, nose, pytest
- Gary Bernhardt's talk, Boundaries talk including a discussion of "Functional Core, Imperative Shell".
- Video of Boundaries talk on youtube
Update: Comment from Harry Percival on 19-Jan-2014
I might have been a bit down on unit tests vs functional tests in that "unit tests never fail comment".
Not true at all, particularly as we've just been thru upgrading django on our core system, and the unit tests really saved our bacon on that one...
Links
- Test-Driven Development with Python
- Obey the Testing Goat - Harry's site dedicated to the book and related posts.
- Python Testing with unittest, nose, pytest
- Gary Bernhardt's talk, Boundaries talk including a discussion of "Functional Core, Imperative Shell".
- Video of Boundaries talk on youtube
- code reuse
- cleanup of resources
- errors vs failures
- focusing your thinking on what you are testing and what you are not
- scoping for efficiency
References
]]>- code reuse
- cleanup of resources
- errors vs failures
- focusing your thinking on what you are testing and what you are not
- scoping for efficiency
References
]]>- code reuse
- cleanup of resources
- errors vs failures
- focusing your thinking on what you are testing and what you are not
- scoping for efficiency
References
]]>- code reuse
- cleanup of resources
- errors vs failures
- focusing your thinking on what you are testing and what you are not
- scoping for efficiency
References
]]>- code reuse
- cleanup of resources
- errors vs failures
- focusing your thinking on what you are testing and what you are not
- scoping for efficiency
References
]]>- code reuse
- cleanup of resources
- errors vs failures
- focusing your thinking on what you are testing and what you are not
- scoping for efficiency
References
]]>Why testing?
- What are the benefits?
- Why automated testing over manual testing?
- Why test first?
- Why do automated testing during development?
- Why test to the user level API?
After describing my ideal test strategy and project, I list:
- Business related, practical benefits of testing
- Personal reasons to embrace testing
- Pragmatic, day to day, developer benefits of testing
Why testing?
- What are the benefits?
- Why automated testing over manual testing?
- Why test first?
- Why do automated testing during development?
- Why test to the user level API?
After describing my ideal test strategy and project, I list:
- Business related, practical benefits of testing
- Personal reasons to embrace testing
- Pragmatic, day to day, developer benefits of testing
Why testing?
- What are the benefits?
- Why automated testing over manual testing?
- Why test first?
- Why do automated testing during development?
- Why test to the user level API?
After describing my ideal test strategy and project, I list:
- Business related, practical benefits of testing
- Personal reasons to embrace testing
- Pragmatic, day to day, developer benefits of testing
Mentioned:
I did the audio processing differently for this episode. Please let me know how it sounds, if there are any problems, etc.
]]>Mentioned:
I did the audio processing differently for this episode. Please let me know how it sounds, if there are any problems, etc.
]]>Mentioned:
]]>