DEV Community: Namah Shrestha

Chapter 6: Test on Commit With Github Actions

Namah Shrestha — Fri, 21 Oct 2022 12:37:26 +0000

This chapter is part of the series:

Understanding the Python Tox Ecosystem

Namah Shrestha ・ Oct 21 ・ 3 min read

#python #tox #testing #pytest
The chapter builds upon the project structure from the previous chapter (Chapter 5). I suggest reading the chapter to understand the project structure.

Chapter 6: Test on Commit With Github Actions

Namah Shrestha ・ Oct 21 ・ 4 min read

#github #testing #python #git

So this is the structure of our project so far.

- src/
    - something/
        - __init__.py
        - py.typed
        - app.py
- tests/
    - __init__.py
    - conftest.py
    - test_app.py
- .gitignore
- LICENSE
- pyproject.toml
- README.md
- requirements.txt
- setup.cfg
- setup.py
- tox.ini

Table of Contents:
- 6.1 - The Need for Github Actions
- 6.2 - Configuring Github Actions
- 6.3 - Understanding Tox GH Actions
- 6.4 - Adding build results to README

6.1 The Need for Github Actions

Everything we did with Tox is only local to our machine. That is, the tests pass in all the version, type check passes in all the versions and linting works in all the versions as well. However, all of it happens on our machine. That is, on our operating system.
How do we know that it passes on other machines? Other operating systems?
Well, this is the “AUTOMATED” part in Automated Testing.
Here we will configure Github Actions to automatically run Tox every time we make a push to the main branch across different machines (OS).

6.2 Configuring Github Actions

To configure Github Actions we need another configuration file. In this case, an entire directory.
We need to create the following files and directories: .github/workflows/<name>.yml.
In this case, name can be whatever we want. We will call it, tests.yml.

Let’s look at the tests.yml file.

name: Tests

on:
  - push
  - pull_request

jobs:
  test:
    runs-on: ${{ matrix.os }}
    strategy:
      matrix:
        os: [ubuntu-latest, windows-latest]
        python-version: ['3.6', '3.7', '3.8', '3.9']

    steps:
    - uses: actions/checkout@v2
    - name: Set up Python ${{ matrix.python-version }}
      uses: actions/setup-python@v2
      with:
        python-version: ${{ matrix.python-version }}
    - name: Install dependencies
      run: |
        python -m pip install --upgrade pip
        pip install tox tox-gh-actions
    - name: Test with tox
      run: tox

We have the name field. This is the name that will show up on our badge in README.md.
We specify that we want to run our workflow to run on push or pull_request.
We only have one job. We call it test.
strategy->matrix is a syntax we use in order to create all combinations of environments that we want to use.
- We have:
```
os: [ubuntu-latest, windows-latest]
python-version: ['3.6', '3.7', '3.8', '3.9']
```
- So there will be 8 virtual environments:
  - ubuntu-latest, 3.6
  - ubuntu-latest, 3.7
  - ubuntu-latest, 3.8
  - ubuntu-latest, 3.9
  - windows-latest, 3.6
  - windows-latest, 3.7
  - windows-latest, 3.8
  - windows-latest, 3.9
- All of these values are preconfigured Github options. We cannot write custom names for these sections. We can find the link to all the supported options at the Github Actions documentation.

Now, we just define what are all the steps.

We checkout the repository.

- uses: actions/checkout@v2
- name: Set up Python ${{ matrix.python-version }}

We setup the version of Python.

uses: actions/setup-python@v2
  with:
    python-version: ${{ matrix.python-version }}

Install the dependencies.

- name: Install dependencies
      run: |
        python -m pip install --upgrade pip
        pip install tox tox-gh-actions

Run tox.
```
- name: Test with tox
    run: tox
```
After the following steps. Whenever we commit and push to Github, we will see a build getting triggered. Github will automatically detect our workflow.
We can play around the Github UI from there.

Finally this is the project structure we have.

- .github/
    - workflows/
        - tests.yml
- src/
    - something/
        - __init__.py
        - py.typed
        - app.py
- tests/
    - __init__.py
    - conftest.py
    - test_app.py
- .gitignore
- LICENSE
- pyproject.toml
- README.md
- requirements.txt
- setup.cfg
- setup.py
- tox.ini

6.3 Understanding Tox GH Actions

Notice in the tests.yml file that we install tox-gh-actions in the steps. We need to understand what this is.

- name: Install dependencies
      run: |
        python -m pip install --upgrade pip
        pip install tox tox-gh-actions

Github already has its own set of actions that mimics what tox does.
We can use tox-gh-actions alone in our tox.ini file, if all we wanted to do was push to Github.
However, we are setting up tox with different blocks, because we want to run the tests locally and tox-gh-actions only runs on Github. We cannot run Github Actions locally.
tox-gh-actions is a tool to make tox and Github Actions work together.
We need to give Github a way to map our Tox environments with the github environments.

If we notice, we already have a gh-actions section on the tox.ini file.

[gh-actions]
python =
    3.6: py36, mypy, flake8
    3.7: py37
    3.8: py38
    3.9: py39

The syntax is as follows:

[gh-actions]
python =
    <github_python_version1>: <tox_env1>, <tox_env2>
        <github_python_version1>: <tox_env3>, <tox_env4>
        ...
    and so on

All we do is list out the name of the github environment and map it to the corresponding tox environments.

Again, our tox environment looks something like this:

[tox]
minversion = 3.8.0
envlist = py36, py37, py38, py39, flake8, mypy
isolated_build = true

So we are basically mapping:
- 3.6 to py36, flake8 and mypy. This is because if we look at the configuration of these environments in tox.ini. Their basepython field is only 3.6. Therefore, we did not map flake8 and mypy to the other versions.
- 3.7 to py37.
- 3.8 to py38.
- 3.9 to py39.

6.3 Adding build results to README

We can add the results of the build in our [README.md](http://README.md) file.
We can do that by adding the following line on our README.md: ![Tests](https://github.com/<Username>/<ProjectName>/actions/workflows/tests.yml/badge.svg).

So our [README.md](http://README.md) file looks something like this.

# Something
A starter project to show how to set up and use automated testing in Python

![Tests](https://github.com/DummyUser/DummyProject/actions/workflows/tests.yml/badge.svg)

So thats our article. Thank you for making it this far. To understand this article visually, checkout the video mentioned in the credits section.

Chapter 5: Testing Multiple Environments with TOX.

Namah Shrestha — Fri, 21 Oct 2022 12:24:23 +0000

This chapter is part of the series:

Understanding the Python Tox Ecosystem

Namah Shrestha ・ Oct 21 '22

#python #tox #testing #pytest
This tutorial builds upon the project structure from Chapter 3 and Chapter 4. I suggest understanding Chapter 3 and Chapter 4 before moving forward in order to understand the project structure.
- Chapter 3:
  
  Chapter 3: Using PyTest, MyPy and flake8 for testing
  
  Namah Shrestha ・ Oct 21 '22
  
  #python #testing #pytest #flake8
- Chapter 4:
  
  Chapter 4: A Quick tour of PyTest
  
  Namah Shrestha ・ Oct 21 '22
  
  #python #pytest #testing #unittesting

So far, this is the structure of our code.

- src/
    - something/
        - __init__.py
        - py.typed
        - app.py
- tests/
    - __init__.py
    - conftest.py
    - test_app.py
- .gitignore
- LICENSE
- pyproject.toml
- README.md
- requirements.txt
- setup.cfg
- setup.py

Table of contents:
- 5.1 - The Need for Tox and the Tox configuration file
- 5.2 - Understanding the Tox environments and variables
- 5.3 - Understanding the flow of Tox environments
- 5.4 - Executing TOX

5.1 The Need for Tox

The code so far has run on our local environment.
How do we know that the code runs on multiple environments? Since we are building packages, we should know which versions of python can install our package and run it.
This is where Tox comes in. To work with Tox we need a tox.ini file which is Tox's own configuration file.

Let’s consider the following tox.ini file in the root directory of the project.

[tox]
minversion = 3.8.0
envlist = py36, py37, py38, py39, flake8, mypy
isolated_build = true

[gh-actions]
python =
    3.6: py36, mypy, flake8
    3.7: py37
    3.8: py38
    3.9: py39

[testenv]
setenv =
    PYTHONPATH = {toxinidir}
deps =
    -r{toxinidir}/requirements_dev.txt
commands =
    pytest --basetemp={envtmpdir}

[testenv:flake8]
basepython = python3.6
deps = flake8
commands = flake8 src tests

[testenv:mypy]
basepython = python3.6
deps =
    -r{toxinidir}/requirements_dev.txt
commands = mypy src

To read more about tox file structure, we can read: https://tox.wiki/en/latest/config.html.

5.2 Understanding the Tox environments and variables

We can read about all of this from [tox.wiki](http://tox.wiki) , https://tox.wiki/en/latest/config.html.
All global settings are defined in the [tox] section. In our case,
```
[tox]
minversion = 3.8.0
envlist = py36, py37, py38, py39, flake8, mypy
isolated_build = true
```
- minversion is the minimum version of tox-library required to parse this tox file.
  - 3.8.0 is the minimum version of tox-library required to parse this tox file.
- envlist is for determining the environment list that toxis to operate on and so on.
- There are many other global setting variables that are available in the tox.wiki website. We do not need to understand everything as of now.
Test environments are defined under the testenvsection and individual testenv:NAMEsections, where NAMEis the name of a specific environment. This section also has a lot of options to set. For our case, we will go through:
- basepython: Name or path to a Python interpreter which will be used for creating the virtual environment.
- deps: Environment dependencies. Installed usually from requirements file or manually written.
- commands: The commands to be called for testing. Only execute if [commands_pre](https://tox.wiki/en/latest/config.html#conf-commands_pre) succeeds. commands_pre is another option we have not talked about.
- setenv: Each line contains a NAME=VALUE environment variable setting which will be used for all test command invocations.
We might also notice {toxinidir} which is a variable inbuilt in tox. We can learning more about changing its working directory: https://stackoverflow.com/questions/52503796/change-tox-workdir.
- For now, we just need to understand that: from tox global settingssection from tox documentation, the .tox directory which is working dir, is created in directory where tox.iniis located.
- Turns out tox also creates a working directory just like git does.
We also have {envtmpdir} which is another variable inbuilt in tox.
- {envdir} basically points to the virtualenv directory that tox creates.
- If we do {envdir}/tmp it points to the tmp directory inside the virtualenv.
- This is what {envtmpdir} points to. Basically {envtmpdir} = {envdir}/tmp.
- It will be cleared each time before the group of test commands is invoked. In our case, we have three group of test commands: a [test] which is inbuilt in tox and two test:NAME which are our custom test groups.
- There are other similar variables: {envlogdir}={envdir/log}. It defines a directory for logging where tox will put logs of tool invocation.
tox-gh-actionsis a tox plugin which helps running tox on GitHub Actions with multiple different Python versions on multiple workers in parallel.

5.3 Understanding the flow of Tox environments

Tox allows us to create a bunch of different virtual environments, install our package into those environments and then run the test groups on each of those environments.

The first four py36, py37, py38, py39, are built-in versions of python that tox already knows about.

[tox]
minversion = 3.8.0
envlist = py36, py37, py38, py39, flake8, mypy
isolated_build = true

Their configuration goes in the testenv block and the tests are run in those environments with the following commands.
```
[testenv]
setenv =
    PYTHONPATH = {toxinidir}
deps =
    -r{toxinidir}/requirements_dev.txt
commands =
    pytest --basetemp={envtmpdir}
```
- We set the PYTHONPATH to {toxinidir}. From the previous section we know it equals to PYTHONPATH=<top level of project directory>. Since, we know toxinidir points to wherever the tox.ini file is located. In our case, it is located at the top level of the project directory.
- As you can see, in testenv , we have set deps=-r{toxinidir}/requirements_dev.txt. From the previous section we know it equals to deps=-r <project_directory>/requirements_dev.txt. Since, we know toxinidir points to wherever the tox.ini file is located. In our case, it is located at the top level of the project directory.
- We install the requirements and then run the pytest --basetemp=<virtualenv>/tmp command in all of the environments passed along. Since, we know that {envtmpdir} points to <virtualenv>/tmp directory.

Then we have the last two environments: flake8, mypy.

[tox]
minversion = 3.8.0
envlist = py36, py37, py38, py39, flake8, mypy
isolated_build = true

flake8 and mypy are not built-in environments in tox. Therefore, we have to create separate testenv:NAME block for them. Which is why we added:

[testenv:flake8]
basepython = python3.6
deps = flake8
commands = flake8 src tests

[testenv:mypy]
basepython = python3.6
deps =
    -r{toxinidir}/requirements_dev.txt
commands = mypy src

Here, testenv:flake8 is the flake8 virtual environment and testenv:mypy is the mypy virtual environment.
Since flake8 and mypy are not versions of python and only commands that we want to run, we need to specify which version of python we want to run on. We do this on basepython.
deps again are all the dependencies. We can specify individual dependencies or we can specify the requirements file.
commands is the actual command that runs in these blocks.
We also have, gh-actions block which we will discuss in the next chapter.

5.4 Executing TOX

Once we have the tox.ini file and the tox command.
To get the tox command, pip install tox.
We can now just run the tox command and everything will be automated.
```
$ tox
```
When we run it, we notice that it takes very long. Why is that?
- When we run the tests locally, it runs on our virtual environment.
- But like we discussed, tox creates a new virtual environment, install everything into that and run tests in all of those environments.
It is advised to run tox only before commit and push. Otherwise, just use pytest , to save time during development.

Chapter 4: A Quick tour of PyTest

Namah Shrestha — Fri, 21 Oct 2022 12:14:53 +0000

This chapter is part of the series:

Understanding the Python Tox Ecosystem

Namah Shrestha ・ Oct 21 ・ 3 min read

#python #tox #testing #pytest
In this section, we will be going through the features of pytest.
Table of Contents:
- 4.1 - Test Discovery
- 4.2 - Parameterising our Tests with @pytest.mark.parameterize
- 4.3 - Skipping Tests
- 4.4 - Handling failing test cases
- 4.5 - Handling tests that raise errors
- 4.6 - fixtures in pytest
  - 4.6.1 - Understanding fixture scopes
- 4.7 - monkeypatching (The correct way to mock code)
  - 4.7.1 - Understanding the need to mock
  - 4.7.2 - Monkeypatch syntax overview
- 4.8 - Understanding Test Coverage

4.1 Test Discover

Test discovery is the process of automatically discovering tests within the specified locations.
There are a lot more use cases of test discovery than whats mentioned in this article. We can specify the configurations on a much more granular level.
However, we are going to look at the default discovery mechanism that we currently have in pytest.
The default implementation is as follows:
- It looks at the tests in our tests/ directory. We specified this directory in the tool.pytest.ini option in pyproject.toml file.
- It then looks for any module (filename in this case) that starts with test_.
- Within each module it looks for functions with test_, it assumes that these are the tests and it runs them.
To know more about pytest test discovery, we can read the documentation.
- Here is a small article: https://docs.pytest.org/en/stable/explanation/goodpractices.html#test-discovery
- Here is an article on how to change the standard test discovery: https://docs.pytest.org/en/7.1.x/example/pythoncollection.html

4.2 Parameterising our Tests

For now, our code has a single test function inside test_app.py.

import pytest
from app import do_something_with_somethingelse, SomethingElse

def test_something() -> None:
    somethingelse1: SomethingElse = SomethingElse(1)
    somethingelse2: SomethingElse = SomethingElse(2)
    somethingelse3: SomethingElse = SomethingElse(3)
    assert do_something_with_somethingelse(somethingelse1) == 'some'
    assert do_something_with_somethingelse(somethingelse2) == 'thing'
    assert do_something_with_somethingelse(somethingelse3) == ''

This test does not indicate the behaviour that we are testing. But later on, we will have multiple tests based on the different tests.
Not only that, notice that in the tests, if one assert statement fails. Then the rest of the assert statements are never executed. The test is considered to have failed.
In order to prevent this from happening, pytest allows parameterization of tests.
It has a @pytest.mark.parameterize decorator using which we can plug in different values for the same use case (same test function).
This allows our tests to run multiple assert statements. If one fails, the others will still run.

Using this our test could look something like:

import pytest
from app import do_something_with_somethingelse, SomethingElse

@pytest.mark.parameterize("dummy_somethingelse_value, dummy_expected_result", [
    (1, 'some'),
    (2, 'thing'),
    (3, '')
])
def test_something(dummy_somethingelse_value, dummy_expected_result) -> None:
    assert do_something_with_somethingelse(SomethingElse(dummy_expected_result)) == \
        dummy_expected_result

The syntax for parameterize is:

@pytest.mark.parameterize('label1, label2, ... and so on', [
    (label1value, label2value, ... and so on),
    (label1value, label2value, ... and so on),
    ...
    and so on
])
def test_dummy(label1, label2, .... and so on) -> None:
    pass

So the main idea behind mark.parameterize is that if one of the cases in parameterize list fails, it still runs the rest of them.
Apart from that, it makes our tests look a lot cleaner.

4.3 Skipping Tests

We can skip tests in pytest by using the @pytest.mark.skip(reason='Any message') decorator.

@pytest.mark.skip(reason='Feature not implemented yet')
def test_skip_sometest() -> None:
    assert some_uninmplemted_feature is not None

When we do TDD (Test Driven Development), we write tests before we implement the functionality.
We usually skip such tests.
There is also another skipif variation of skip which lets us skip based on conditions. For example, if the operating system is Windows, or the version of Python is not supported, etc.

4.4 Handling Failing Tests

We might have tests that are bound to fail. These tests can be used as:
- Tests to assure that things that are supposed to fail (like some virtual scenario), do fail.
- Documentation to better understand the system. To show that certain settings will fail.
These tests when executed will show up as failure and fail the entire build.
We can avoid that by deliberately marking them as tests that are supposed to fail.

We can achieve this with the pytest.mark.xfail decorator.

@pytest.mark.xfail
def test_zero_division() -> None:
    assert 1 / 0 == 1

However, we should not mark those tests that raise errors as failing tests. This brings us to the next topic.

4.5 Handling Tests that raise Exceptions

We might want to make sure certain scenarios raise a certain exceptions.

This can be handled by using the context manager called pytest.raises(Exception).

def zero_division() -> float:
    return 1/0

def test_zero_division() -> None:
    with pytest.raises(ZeroDivisionError):
        zero_division()

As we can see, there is an exception expected when we run zero_division. We can handle it with pytest.raises.
This test will now fail if ZeroDivisionError is not raised.

4.6 `fixtures` in `pytest`

Fixtures are used when multiple tests require a certain amount of setup that they all share in common.
For example, tests that require a database connection.
- In such cases, it is better to create the connection and share it with tests.
- Rather than creating a connection for every test.
- So we can create Fixtures that get passed to our tests.
In unittest this is done by the setUp method. It creates objects that can be shared throughout the test methods.
By convention if we create a file called conftest.py, and create a fixture in that file, it will be available for all of our tests based on thescope of the fixture.

So we create conftest.py in our tests/ directory alongside test_app.py and create fixtures there as follows:

import pytest

@pytest.fixture(scope="session")
def db_con():
    db_url = "driver+dialect://username:password@host:port/database"
    db = DatabaseLibrary()
    with db.connection(db_url) as conn:
        yield conn

Notice we have scopes in pytest. We will look at what scopes are.
Fixture scopes basically define how many times a fixture will run based on the area it covers.

4.6.1 Understanding `fixture` scopes

To learn more about fixture scope, we can go: https://betterprogramming.pub/understand-5-scopes-of-pytest-fixtures-1b607b5c19ed.
Scope basically has to do with the scope of the fixture as in, upto where the fixture is shared. There are five types of scopes: function, class, module, package, session.

function scope:

This is the default scope without explicitly adding scope='function'.
The fixture will be executed per test function.
This is very heavy task.

This fixture is suitable for single use functions.

import pytest

@pytest.fixture()
def only_used_once():
    with open("app.json") as f:
        config = json.load(f)
    return config

This fixture is suitable when it handles very lightweight operations such as returning a constant or a different value every time.

import pytest
from datetime import datetime

@pytest.fixture()
def light_operation():
    return "I'm a constant"

@pytest.fixture()
def need_different_value_each_time():
    return datetime.now()

class scope:
- This scope runs the fixture per test class.
- If we have couple of test functions that do similar things, we can put them in the same class.
- To know more about grouping tests in classes.
  - Conventions for Python Test Discovery: https://docs.pytest.org/en/stable/explanation/goodpractices.html#test-discovery
  - Group multiple tests in a class: https://docs.pytest.org/en/stable/getting-started.html#group-multiple-tests-in-a-class
  - The parent StackOverFlow thread: https://stackoverflow.com/questions/20277058/py-test-does-not-find-tests-under-a-class#:~:text=test does not find tests under a class,-Ask Question
  - How to test unittest.TestCase based classes: https://docs.pytest.org/en/7.1.x/how-to/unittest.html
  - Changing Python standard test discovery: https://docs.pytest.org/en/7.1.x/example/pythoncollection.html
- Now that we know how to group tests in classes and test discovery for classes, we will see how we can use fixtures on these test classes with scope="class".
- We can use @pytest.mark.usefixtures("fixturename") decorator with the test class.
```
@pytest.fixture(scope="class")
def dummy_data(request):
    request.cls.num1 = 10
    request.cls.num2 = 20
    logging.info("Execute fixture")

@pytest.mark.usefixtures("dummy_data")
class TestCalculatorClass:
    def test_distance(self):
        logging.info("Test distance function")
        assert distance(self.num1, self.num2) == 10

    def test_sum_of_square(self):
        logging.info("Test sum of square function")
        assert sum_of_square(self.num1, self.num2) == 500
```
- The fixture will be executed once per test class before the test methods.

There is a special usage of yield statement in pytest that allows us to run the fixture after all the test functions.

The code before yield acts as setup code.
The code after yeild acts as teardown code.

For example, testing a database.

@pytest.fixture(scope="class")
def prepare_db(request):
    # pseudo code
    connection = db.create_connection()
    request.cls.connection = connection
    yield
    connection = db.close()

@pytest.mark.usefixtures("prepare_db")
class TestDBClass:
    def test_query1(self):
        assert self.connection.execute("..") == "..."

    def test_query2(self):
        assert self.connection.execute("..") == "..."

We can yield values to any test that wants it and the remaining code will act as the teardown code.

module and package scopes:
- The scope='module' runs the fixture per module (per file).
  - A module may contain multiple functions as well as classes.
  - No matter how many tests are in the module, the fixture is run only once.
- The scope='package' runs the fixture per package (directory).
  - A package contains one or more modules.
  - No matter how many modules there are, the fixture is run only once.
- An example would be:
```
@pytest.fixture(scope="module")
def read_config():
    with open("app.json") as f:
        config = json.load(f)
        logging.info("Read config")
    return config
```
- We might want to read config only once per module or only once throughout the entire package.
session scope:
- Every time we run pytest, it is considered to be one session.
- The scope='session' makes sure the fixture only executes per session.
- Session scopes are designed for expensive operations like truncating a table or loading a test set to a database.
We can read more about fixture topics such as autouse and execution order of fixtures. We will look at them when required.

4.7 Monkey Patching in PyTest

Monkey patching is the process of changing the declaration of code during runtime.
This is mocking done right.
To understand mocking and test-driven development in Python, you can check out my tutorial series on TDD in Python: https://www.youtube.com/watch?v=NAjCDS-qxrQ&list=PLVWk3kKbCAAuPPr_eh4KNKdL2hDSNFH3H.
TLDW(Too long didn’t watch?): Mocking lets us replace methods with dummy objects during runtime.

4.7.1 Understanding the need to mock

Why would we want to mock anything?
To understand this you need to understand the principals of unit testing:
- Unit testing are the fastest tests. Why?
- It is testing the functionality of a single unit, without any external dependencies.
- Say you test a function which calls the database.
- You would only want to test the flow of such a function without making the call to the actual database.
- How do you do that? You basically, mock the entire database connection object and replace it with a dummy object.
- You can set whatever values you want that dummy object to return, create whatever dummy functions are required along with their return types. You can mimic the entire database connection’s set of methods if you want.
- What this allows us to do is set dummy values for all the external calls that are within our function and set default results for them.
- With this we can setup a fake scenario without actually making external calls.
- This is why unit tests are fast.
- Integration testing is on the other hand is testing of the actual values in which case, we would test the actual results from the external calls and evaluate them. Thats why Integration tests are slower than unit tests.
This is one of the reasons we use mock.
Monkey patching gives us a better interface than barebones mock library.

4.7.2 Monkeypatch syntax overview

Fixtures can also depend on other fixtures. monkeypatching is such a fixture which is available to all functions.

Let’s create a fixture:

import pytest

@pytest.fixture(scope="function")
def capture_stdout(monkeypatch)
    std_output: dict = {'output': '', 'write_count': 0}
    def fake_writer(s) -> dict:
        std_output['output'] += s
        std_output['write_count'] += 1
        return std_output

    monkeypatch.setattr(sys.stdout, 'write', fake_writer)
    return std_output

def test_print(capture_stdout):
    print("Hello")
    assert capture_stdout['output'] == "Hello"

What we did here is replace sys.stdout.write with fake_writer which returns the captured dictionary.
Every time a test function uses capture_stdout fixture, the environment within the test changes where sys.stdout.write is replaced with fake_writer.
Whenever any function calls sys.stdout within the function scope will be making a call to fake_writer instead. In our example, we call print will calls to sys.stdout.
The return value is captured in the capture_stdout variable and can be used to assert results.
This is how we mock things.
But why use monkeypatching instead of just mocks?
- At the end of the test, monkeypatching makes sure that everything is undone and sys.out.writer goes back to its original value.
- In unittest we use mock.patch as decorators and context managers. This also makes sure that everything is undone at the end of the test.

4.8 UNDERSTANDING TEST COVERAGE

We have put --cov options in pyproject.toml.
This shows us test coverage in percentages.
Here 100% test coverage means all our tests combined and touched every single line of executable code in the src.
Any percentage lesser means that some executable code was not tested by our tests.
However, having 100% test coverage does denote that there are no bugs. It all depends. However, it’s good to have 100% code coverage.

Chapter 3: Using PyTest, MyPy and flake8 for testing

Namah Shrestha — Fri, 21 Oct 2022 12:06:29 +0000

This chapter is part of the series:

Understanding the Python Tox Ecosystem

Namah Shrestha ・ Oct 21 '22

#python #tox #testing #pytest
Please consider reading the previous chapter (Chapter 2) before moving forward. This chapter builds upon the project structure discussed in the previous chapter (Chapter 2).

Chapter 2: The Need Of A Project Structure In Python Testing

Namah Shrestha ・ Oct 21 '22

#python #tox #testing #pytest

From the previous chapter (Chapter 2), we have the following project structure:

    - src/
    - something/
        - __init__.py
        - app.py
    - tests/
        - __init__.py
        - test_app.py
    - .gitignore
    - LICENSE
    - pyproject.toml
    - README.md
    - requirements.txt
    - setup.cfg
    - setup.py

Here we are going to setup pytest, mypy and flake8.
TABLE OF CONTENTS
- 3.1 - Adding new dependencies to requirements
- 3.2 - Adding to our metadata in setup.cfg
- 3.3 - Adding python configurations to pyproject.toml

3.1 Adding new dependencies to requirements

Now we need to install more libraries. Namely pytest, mypy and flake8.
So our requirements.txt file looks something like this. We have added dependencies for pytest:
```
flake==3.9.4
tox==3.24.3
pytest==6.2.5
pytest-cov==2.12.1
mypy==0.910
```
Instead of directly overwriting the requirements.txt file, we create a new file called requirements_dev.txt. Since testing is required in dev environment.
So we have two requirement files:
- requirements.txt which we use while running our code:
```
requests==2.26.0
```
- requirements_dev.txt which holds dev dependencies like our test, lint and type check libraries.
```
flake==3.9.4
tox==3.24.3
pytest==6.2.5
pytest-cov==2.12.1
mypy==0.910
```
While running tests we will use requirements_dev.txt file to install dependencies.

3.2 Adding to our metadata in `setup.cfg`

Our setup.cfg file looks something like this:

    [metadata]
    name = something
    description = just some dummy codebase
    author = Coding with Zim
    license = MIT
    license_file = LICENSE
    platforms = unix, linux, osx, cygwin, win32
    classifiers = 
        Programming Language :: Python :: 3
        Programming Language :: Python :: 3 :: Only
        Programming Language :: Python :: 3.6
        Programming Language :: Python :: 3.7
        Programming Language :: Python :: 3.8
        Programming Language :: Python :: 3.9

    [options]
    packages =
        something
    install_requires =
        requests>=2
    python_requires = >=3.6
    package_dir =
        =src
    zip_safe = no

    [options.extras_require]
    testing=
        pytest>=6.0
        pytest-cov>=2.0
        mypy>=0.910
        flake8>=3.9
        tox>=3.24

    [options.package_data]
    something = py.typed

    [flake8]
    max-line-length = 160

options.extras_require are optional dependencies. We can read more about it here: https://setuptools.pypa.io/en/latest/userguide/dependency_management.html
options.package_data is a type of Data File Support , we can read more about it here: https://setuptools.pypa.io/en/latest/userguide/datafiles.html. We are basically using it to denote that our code is type-hinted, which means we are using types in the code.
For this to work we need to create a py.typed blank file in our something directory alongside __init__.py.
flake8 is the configuration for the flake8 linter that we will be using. Here we are only saying that the maximum line length is 160.
So our flake8 configuration is stored in the cfg file and our python configuration is stored in our pyproject.toml file.

3.3 Adding python configurations to `pyproject.toml`

Our pyproject.toml file looks something like this:

[build-system]
requires = ["setuptools>=42.0", "wheel"]
build-backend = "setuptools.build_meta"

[tool.pytest.ini_options]
addopts = "--cov=something"
testpaths = [
    "tests",
]

[tool.mypy]
mypy_path = "src"
check_untyped_defs = true
disallow_any_generics = true
ignore_missing_imports = true
no_implicit_optional = true
show_error_codes = true
strict_equality = true
warn_redundant_casts = true
warn_return_any = true
warn_unreachable = true
warn_unused_configs = true
no_implicit_reexport = true

We already discussed about the build-system.
tool.pytest.ini_options are pytest tool options during the execution of tests. In our case we have added the --cov=something option in addopts so that we see the test coverage. testpaths basically denotes all the directories containing tests.
tool.mypy are mypy tool options. To learn about mypy: https://realpython.com/lessons/type-checking-mypy/#:~:text=“Mypy is an optional static,background on the Mypy project.

So, now we install the dev dependencies with pip:

(env)yourproject$ pip install -r requirements_dev.txt

Finally we should be able to run our test with pytest, check linting with flake8 and type check with mypy.

$ pytest # this command will test our code with default test discovery mechanism.
$ mypy # this command will run type checks on our code with mypy.
$ flake8 # this command will check code linting.

Chapter 2: The Need Of A Project Structure In Python Testing

Namah Shrestha — Fri, 21 Oct 2022 11:04:02 +0000

This chapter is part of the series:

Understanding the Python Tox Ecosystem

Namah Shrestha ・ Oct 21 ・ 3 min read

#python #tox #testing #pytest
Please consider reading the previous chapter (Chapter 1) before moving forward. This chapter builds upon the project structure discussed in the previous chapter (Chapter 1).

Chapter 1: The Need For Test Automation

Namah Shrestha ・ Oct 21 ・ 3 min read

#python #tox #testing #pytest
From the previous chapter (Chapter 1), we have the following project structure:
```
- README.md
- LICENSE
- .gitignore
- app.py
- test_app.py
```
We would want separate src and tests directories.

In test_app.py we are picking the pytest solution mentioned in the previous chapter (Chapter1). Because it is a easier to use compared to other testing libraries or frameworks:

import pytest
from app import simple_calculator_function

def test_simple_calculator_function() -> None:
    assert simple_calculator_function("5*(4+5)") == 45 # test addition and multiplication
    assert simple_calculator_function("10 - (100/2)") == -40 # test subtraction and division. 
    assert simple_calculator_function("'a' + 'b'") == 'ab' # test string concatenation

Table of Contents:
- 2.1 - Understanding the problem with import statements
- 2.2 - Solution to the problem with import statements
- 2.3 - Making our application installable
  - 2.3.1 - Understanding the pyproject.toml file
  - 2.3.2 - Understanding the setup.py file
  - 2.3.3 - Understanding the setup.cfg file

2.1 Understanding the problem with import statements.

Our test file looks something like this:

import pytest
from app import simple_calculator_function

def test_simple_calculator_function() -> None:
    assert simple_calculator_function("5*(4+5)") == 45 # test addition and multiplication
    assert simple_calculator_function("10 - (100/2)") == -40 # test subtraction and division. 
    assert simple_calculator_function("'a' + 'b'") == 'ab' # test string concatenation

The import statement from app import simple_calculator_function assumes that app.py is on the same folder as the test_app.py and therefore this kind of import works.
We do not want to depend on this feature for tests. We want our tests to run no matter where they are.
Here, to make sure that the import works, we would need to make sure that test_app.py and app.py are in the same directory.
In case they are in different directories, we need to make sure we run both tests and the application from a common working directory. This working directory is outside both tests and src directories
In this case, the import statement in the test_app.py file would be:
```
    from <common_working_directory>.<app_directory>.app import simple_calculator_function.
```
In this case, the tests also need to be run from the common_working_directory. The test directory would be: <common_working_directory>/tests/test_*.py.
This stops us from running the tests from anywhere and now we have to depend on having the same working directory as well.
We need to make sure that import works from anywhere and doesn't depend on the directory structure.
The way to make that happen is to make your project an installable project.

2.2 Solution to the problem with import statements.

The solution to the import problem is to turn your project into an installable package.
We need to setup before applying the solution. This is what we will do in this section.
So lets move on with a new folder structure. We create src/simple_calculator/ and tests/ directories.
```
- src/
    - simple_calculator/
        - __init__.py
        - app.py
- tests/
    - __init__.py
    - test_app.py
- .gitignore
- LICENSE
- README.md
```
The app.py is placed inside src/simple_calculator/ along with an __init__.py file and test_app.py is placed inside tests/ along with an __init__.py file.
As soon as we create the new directory we get an import error on the test file when we run it.
- Unresolved Reference 'app'
- This is because the test file can no longer find app. They are in different directories.
To make it find the app, we can import from the project directory's root and run tests also from the same directory like we mentioned eariler. This would mean the import statement inside test_app.py would look like:
```
from src.simple_calculator.app import simple_calculator_function
```
Like we mentioned earlier, the problem with this is that we need to run the test also from the project directory.
Again the idea is that would like to run our tests from anywhere without worrying about directory structures for imports.
To enable that we can expect our code to function as a library so that imports can happen from anywhere.
This means making our application installable. So that the following import works after installing our package in the virtual environment with pip.
```
from simple_calculator.app import simple_calculator_function
```
Now no matter where the test is it can use the same import statement everywhere. This solves the problem of having to depend on directory structure for imports.

2.3 Making our application installable.

To make our application installable, we need to add a bunch of configuration files.
- This is an open issue in the Python community.
- The idea is, we shouldn’t need these many files to make our application installable.
- Things could have been easier maybe, but, that is how it is at the moment.
NOTE: The structure that we will follow using setup.py, setup.cfg and pyproject.toml are not required to be the same always. setup.py perfectly supports entire functionalities. We can write the entire configurations on any one of these files if we have to. We are just organising our code better.
If you look at the documentation of setuptools: https://setuptools.pypa.io/en/latest/index.html. Then you’ll see that each and every configuration field in the example files has a counter part in each of the file types.
The community is pushing the configuration more towards the toml file and just leaving the metadata in the cfg file.

2.3.1 Understanding the `pyproject.toml` file.

The first file we will look at is pyproject.toml.
In the early days of Python, there was only one way to install packages. We needed a setup.py file.
But nowadays, there are several options such as Poetry and other such examples.
We can still stick to using the setup.py way and that is what we will be doing in this article.

We can do this by inserting a build-backend to our [build-system] in our pyproject.toml file.

[build-system]
requires = ["setuptools>=42.8", "wheel"]
build-backend = "setuptools.build_meta"

We have setup build-backed to use setuptools.build_meta, this will make our project run code in setup.py. The build-backend requires setuptools and we mention that in the requires section.
So the next file to look at is setup.py, because our build-backend is setuptools.

2.3.2 Understanding the `setup.py` file.

Next is the setup.py file.
In the early days, setup.py used to be the place containing the installation script.
It would do everything required to do in order to install a python package.
We can run arbitrary code inside setup.py. Since it is a python script.
This is seen as a security risk and therefore, more and more code is being stripped out of the setup.py file and put into one of these other configuration file.

Let’s create a basic setup.py file.

import setuptools

if __name__ == "__main__":
    setuptools.setup()

This basic file is going to allow us to install our package in editable mode. Since, we have mentioned setuptools.build_meta in build-system in pyproject.toml, when we run the install script, setup.py will be executed.

2.3.3 Understanding the `setup.cfg` file.

To store the metadata of the project such as Title and Description, we create a setup.cfg file.

The file could look as follows:

[metadata]
name = something
description = just some dummy codebase
author = Coding with Zim
license = MIT
license_file = LICENSE
platforms = unix, linux, osx, cygwin, win32
classifiers = 
    Programming Language :: Python :: 3
    Programming Language :: Python :: 3 :: Only
    Programming Language :: Python :: 3.6
    Programming Language :: Python :: 3.7
    Programming Language :: Python :: 3.8
    Programming Language :: Python :: 3.9

[options]
packages =
    something
install_requires =
    requests>=2
python_requires = >=3.6
package_dir =
    =src
zip_safe = no

NOTE: In [options] we have new line after = sign. This signifies that there can be more than one of these values. So, packages, install_requires, package_dir can have multiple values.
packages are the names of packages that we are creating.
install_requires are the names of requirements. Need to look at how to do this with requirements.txt.
python_requires denotes the versions of python supported.
package_dir is the directory where our application module lives. Inside the src directory. There might be other names. We are just going with the naming convention.
zip_safe is no. No idea what it is for now.
Why use this file instead of putting everything in setup.py?
Since this is just a configuration file and not a python script, we don’t have to worry about it executing arbitrary code which was the case with setup.py. This is what the community wants. They want to push everything into different configuration files.
Then we add a requirements.txt file which contains all our dependencies.
```
requests==2.26.0
```
In our case, it only contains requests for demo purposes.
NOTE: In setup.py we gave a version >=2. In requirements.txt , we specify the actual version. That is best practice.

With this our project structure looks something like this:

- src/
    - something/
        - __init__.py
        - app.py
- tests/
    - __init__.py
    - test_app.py
- .gitignore
- LICENSE
- pyproject.toml
- README.md
- requirements.txt
- setup.cfg
- setup.py

Now we should be able to install it with pip by the following command:

your_project_folder$ pip install -e . # e means editable i guess.

Chapter 1: The Need For Test Automation

Namah Shrestha — Fri, 21 Oct 2022 10:42:07 +0000

This chapter is part of the series:

Understanding the Python Tox Ecosystem

Namah Shrestha ・ Oct 21 ・ 2 min read

#python #tox #testing #pytest
At first, we need to understand, how we can test python code without a testing library.
We will then look into how to test with an existing library.
Then we will look at how tox fits in the ecosystem.

1.1 Testing Without A Library

Consider the following code structure of a Python application:
```
- README.md
- LICENSE
- .gitignore
- app.py
```
We may have various assert statements written inside app.py. However, these tests need to be executed manually by calling the function.
Consider the following code for app.py.

  def simple_calculator_function(evaluation_string: str) -> typing.Any:
    '''
    Reads an evaluation string.
    Evaluates it and returns the result.
    For example, eval("5*(4+5)") = 45.

    params:
        evaluation_string: str: The string that will be evaluated.
    '''
    try:
        return eval(evaluation_string)
    except Exception as e:
        raise Exception(e)

   def test_simple_calculator_function() -> None:
        assert simple_calculator_function("5*(4+5)") == 45 # test addition and multiplication
        assert simple_calculator_function("10 - (100/2)") == -40 # test subtraction and division. 
        assert simple_calculator_function("'a' + 'b'") == 'ab' # test string concatenation

As you can see, test_simple_calculator_function will not run automatically unless called. We want to automate this.
The first step is to create a separate test_file which uses libraries to write tests. The new project code would be:
```
- README.md
- LICENSE
- .gitignore
- app.py
- test_app.py
```
We have added a test_app.py which will work on libraries.

1.2 USING AN EXISTING TESTING LIBRARY

We have libraries such as the unittest library using which we can write test subclasses that are auto-detected and run automatically.

Example unittest subclass:

import unittest
from app import simple_calculator_function

class TestSomething(unittest.TestCase):
    def test_simple_calculator_function(self) -> None:
        self.assertEqual(simple_calculator_function("5*(4+5)"), 45)
        self.assertEqual(simple_calculator_function("10-(100/2)"), -40)
        self.assertEqual(simple_calculator_function("'a' + 'b'"), 'ab')

We can run this code with unittest tool in the shell as:
```
$ python -m unittest discover -s './' -p 'test_*.py'
```
- Here, unittest discover discovers all the subclasses of unittest.TestCase, i.e. those classes that have inherited unittest.TestCase.
- -s flag denotes the start directory of where the tests are located. In this case, we can stay in the current working directory.
- -p flag denotes the pattern of the names of test files. In this case, the test file naming pattern is test_*.py , where * can be replaced with any name.
We also have the pytest library which is not inbuilt and needs to be installed separately.

  $ pip install pytest

For example, pytest test file.

import pytest
from app import simple_calculator_function

def test_simple_calculator_function() -> None:
    assert simple_calculator_function("5*(4+5)") == 45 # test addition and multiplication
    assert simple_calculator_function("10 - (100/2)") == -40 # test subtraction and division. 
    assert simple_calculator_function("'a' + 'b'") == 'ab' # test string concatenation

pytest can autodetect tests. We can just run pytest in the shell and all tests will run.

   $ pytest

The test detection algorithm also known as the test discovery standard is is used to detect tests by default unless external modifications are made.
There are other testing frameworks such as Nose, DocTest, etc. which will not be covered in this article.

1.3 TOX USE CASE IN THE ECOSYSTEM

Tox is just another automation tool for testing.
What exactly does it automate?
- Since we are building a package, we need to make sure that our package runs on different versions of Python.
- The tests that we have in pytest will run on the local version of the virtualenv that we are currently on. So, it will only check one version of python.
- We need to make sure these tests run passes on all versions of Python.
- This is what Tox automates. Multi-version testing.
How does Tox do this?
- Tox creates a virtual environment for each version of python and/or the operating system that we specify.
- It runs the tests in all those environments and makes sure that our package works on those versions as well.
When we run things on github actions :
- We need to map Tox commands to github actions , essentially because github actions is completely capable of doing what Tox is doing.
- We are only installing Tox to automate testing locally on our machines while developing.
- Since we have a working Tox file, why create another github action section for the thing already automated in Tox.
- We just map Tox environments to github action environments.

Understanding the Python Tox Ecosystem

Namah Shrestha — Fri, 21 Oct 2022 10:25:36 +0000

This tutorial will show you how to automate testing for python projects using tox.
If you've ever worked on a python package, chances are you have seen files like: setup.cfg, setup.py, pyproject.toml, tox.ini, etc.
This tutorial explains what they are as well as walks you through how you can use them to your benefit.
Table Of Contents
- Chapter 1: The Need For Test Automation
  - 1.1 - Testing Without A library
  - 1.2 - Using an Existing Testing Library
  - 1.3 - Understanding the TOX Use Case in the Eco System
    
    Chapter 1: The Need For Test Automation
    
    Namah Shrestha ・ Oct 21 ・ 3 min read
    
    #python #tox #testing #pytest
- Chapter 2 - The Need of A project Structure in Python Testing
  - 2.1 - Understanding the problem with import statements
  - 2.2 - Solution to the problem with import statements
  - 2.3 - Making our application installable
    - 2.3.1 - Understanding the pyproject.toml file
    - 2.3.2 - Understanding the setup.py file
    - 2.3.3 - Understanding the setup.cfg file
      
      Chapter 2: The Need Of A Project Structure In Python Testing
      
      Namah Shrestha ・ Oct 21 ・ 6 min read
      
      #python #tox #testing #pytest
- Chapter 3 - Using pytest, mypy and flake8
  - 3.1 - Adding new dependencies to requirements
  - 3.2 - Adding to our metadata in setup.cfg
  - 3.3 - Adding python configurations to pyproject.toml
    
    Chapter 3: Using PyTest, MyPy and flake8 for testing
    
    Namah Shrestha ・ Oct 21 ・ 3 min read
    
    #python #testing #pytest #flake8
- Chapter 4 - A Quick Tour of Pytest
  - 4.1 - Test Discovery
  - 4.2 - Working with parameterising
  - 4.3 - Skipping Tests
  - 4.4 - Handling Failing Tests without breaking the build
  - 4.5 - Handling Tests that raise errors
  - 4.6 - Working with fixtures
    - 4.6.1 - Understanding fixture scopes
  - 4.7 - Working with monkey patching
    - 4.7.1 - Understanding the need to mock
    - 4.7.2 - Monkeypatch syntax overview
  - 4.8 - Understanding test coverage
    
    Chapter 4: A Quick tour of PyTest
    
    Namah Shrestha ・ Oct 21 ・ 10 min read
    
    #python #pytest #testing #unittesting
- Chapter 5 - Test multiple environments with Tox
  - 5.1 - The Need for Tox and the Tox configuration file
  - 5.2 - Understanding the Tox variables
  - 5.3 - Understanding the flow of tox environments
  - 5.4 - Executing Tox
    
    Chapter 5: Testing Multiple Environments with TOX.
    
    Namah Shrestha ・ Oct 21 ・ 5 min read
    
    #python #pytest #tox #testing
- Chapter 6 - Test on commit with Github Actions
  - 6.1 - The Need for Github Actions
  - 6.2 - Configuring Github Actions
  - 6.3 - Understanding Tox GH Actions
  - 6.4 - Adding Build Results to README
    
    Chapter 6: Test on Commit With Github Actions
    
    Namah Shrestha ・ Oct 21 ・ 4 min read
    
    #github #testing #python #git
Credits - Study Material
- This article is based on the following youtube video: https://www.youtube.com/watch?v=DhUpxWjOhME
- Please check it out. This video offers a visual counterpart to this article. It is the original video this article is based out of.
- Other articles used throughout the article to understand various concepts better:
  - SetupTools Documentation - https://setuptools.pypa.io/en/latest/index.html
  - Type Checking with MyPy - https://realpython.com/lessons/type-checking-mypy/#:~:text=%E2%80%9CMypy%20is%20an%20optional%20static,background%20on%20the%20Mypy%20project
  - Test Discover in PyPy - https://docs.pytest.org/en/stable/explanation/goodpractices.html#test-discovery
  - Grouping multiple tests in a class - https://docs.pytest.org/en/stable/getting-started.html#group-multiple-tests-in-a-class
  - Understanding grouping of tests in a class - https://stackoverflow.com/questions/20277058/py-test-does-not-find-tests-under-a-class#:~:text=test%20does%20not%20find%20tests%20under%20a%20class,-Ask%20Question
  - Testing unittest based classes - https://docs.pytest.org/en/7.1.x/how-to/unittest.html
  - Change the standard in Test Discovery - https://docs.pytest.org/en/7.1.x/example/pythoncollection.html
  - Fixture Scopes - https://betterprogramming.pub/understand-5-scopes-of-pytest-fixtures-1b607b5c19ed
  - Understanding the structure of tox configuration file: https://tox.wiki/en/latest/config.html
- Finally my TDD In Python course: https://www.youtube.com/watch?v=NAjCDSqxrQ&list=PLVWk3kKbCAAuPPr_eh4KNKdL2hDSNFH3H

DEV Community: Namah Shrestha

Chapter 6: Test on Commit With Github Actions

Understanding the Python Tox Ecosystem

Namah Shrestha ・ Oct 21 ・ 3 min read

Chapter 6: Test on Commit With Github Actions

Namah Shrestha ・ Oct 21 ・ 4 min read

Table of Contents:

6.1 The Need for Github Actions

6.2 Configuring Github Actions

6.3 Understanding Tox GH Actions

6.3 Adding build results to README

Chapter 5: Testing Multiple Environments with TOX.

Understanding the Python Tox Ecosystem

Namah Shrestha ・ Oct 21 '22

Chapter 3: Using PyTest, MyPy and flake8 for testing

Namah Shrestha ・ Oct 21 '22

Chapter 4: A Quick tour of PyTest

Namah Shrestha ・ Oct 21 '22

Table of contents:

5.1 The Need for Tox

5.2 Understanding the Tox environments and variables

5.3 Understanding the flow of Tox environments

5.4 Executing TOX

Chapter 4: A Quick tour of PyTest

Understanding the Python Tox Ecosystem

Namah Shrestha ・ Oct 21 ・ 3 min read

4.1 Test Discover

4.2 Parameterising our Tests

4.3 Skipping Tests

4.4 Handling Failing Tests

4.5 Handling Tests that raise Exceptions

4.6 fixtures in pytest

4.6.1 Understanding fixture scopes

4.7 Monkey Patching in PyTest

4.7.1 Understanding the need to mock

4.7.2 Monkeypatch syntax overview

4.8 UNDERSTANDING TEST COVERAGE

Chapter 3: Using PyTest, MyPy and flake8 for testing

Understanding the Python Tox Ecosystem

Namah Shrestha ・ Oct 21 '22

Chapter 2: The Need Of A Project Structure In Python Testing

Namah Shrestha ・ Oct 21 '22

TABLE OF CONTENTS

3.1 Adding new dependencies to requirements

3.2 Adding to our metadata in setup.cfg

3.3 Adding python configurations to pyproject.toml

Chapter 2: The Need Of A Project Structure In Python Testing

Understanding the Python Tox Ecosystem

Namah Shrestha ・ Oct 21 ・ 3 min read

Chapter 1: The Need For Test Automation

Namah Shrestha ・ Oct 21 ・ 3 min read

Table of Contents:

2.1 Understanding the problem with import statements.

2.2 Solution to the problem with import statements.

2.3 Making our application installable.

2.3.1 Understanding the pyproject.toml file.

2.3.2 Understanding the setup.py file.

2.3.3 Understanding the setup.cfg file.

Chapter 1: The Need For Test Automation

Understanding the Python Tox Ecosystem

Namah Shrestha ・ Oct 21 ・ 2 min read

1.1 Testing Without A Library

1.2 USING AN EXISTING TESTING LIBRARY

1.3 TOX USE CASE IN THE ECOSYSTEM

Understanding the Python Tox Ecosystem

Table Of Contents

Chapter 1: The Need For Test Automation

Namah Shrestha ・ Oct 21 ・ 3 min read

Chapter 2: The Need Of A Project Structure In Python Testing

Namah Shrestha ・ Oct 21 ・ 6 min read

Chapter 3: Using PyTest, MyPy and flake8 for testing

Namah Shrestha ・ Oct 21 ・ 3 min read

Chapter 4: A Quick tour of PyTest

Namah Shrestha ・ Oct 21 ・ 10 min read

Chapter 5: Testing Multiple Environments with TOX.

Namah Shrestha ・ Oct 21 ・ 5 min read

Chapter 6: Test on Commit With Github Actions

Namah Shrestha ・ Oct 21 ・ 4 min read

Credits - Study Material

4.6 `fixtures` in `pytest`

4.6.1 Understanding `fixture` scopes

3.2 Adding to our metadata in `setup.cfg`

3.3 Adding python configurations to `pyproject.toml`

2.3.1 Understanding the `pyproject.toml` file.

2.3.2 Understanding the `setup.py` file.

2.3.3 Understanding the `setup.cfg` file.