📝 Update test section

* Switch to uv
* Switch form items to cusy.tasks
* Add hypothesis extensions
* Update mocking, hypothesis and glossary
* Add Test Driven Development

Author: veit

docs/appendix/checks.rst

@@ -112,7 +112,7 @@ Checks
   * ``1`` → True
   * ``0`` → False
   * ``-1`` → True
-  * ``[0]`` → True (List with one item)
+  * ``[0]`` → True (List with one task)
   * ``1 and 0`` → False
   * ``1 > 0 or []`` → True
 
@@ -858,18 +858,19 @@ Checks
      ├── README.rst
      ├── pyproject.toml
      └── src
-         └── items
-             ├── __init__.py
-             ├── api.py
-             ├── cli.py
-             └── db.py
+         └── cusy
+             └── tasks
+                 ├── __init__.py
+                 ├── api.py
+                 ├── cli.py
+                 └── db.py
 
 * Think about how you want to fulfil the above tasks. Which libraries and
   modules can you think of that could fulfil this task? Sketch the code for the
   modules of the Python API, the command line interface and the database
   connection.
 
-  I would create a :class:`DB` class in :file:`src/items/db.py` for
+  I would create a :class:`DB` class in :file:`src/cusy/tasks/db.py` for
   communication with the database, in the following example for `tinydb
   <https://tinydb.readthedocs.io/en/latest/>`_:
 
@@ -884,80 +885,80 @@ Checks
                  db_path / f"{db_file_prefix}.json", create_dirs=True
              )
 
-         def create(self, item: dict):
-             """Create an item
+         def create(self, task: dict):
+             """Create a task
 
              Returns:
-                 id: The items id.
+                 id: The tasks id.
              """
 
              return id
 
          def read(self, id: int):
-             """Reads an item.
+             """Reads a task.
 
              Args:
-                 id (int): The item id of an item.
+                 id (int): The task id of an task.
              Returns:
-                 item: The item object."""
-             return item
+                 task: The task object."""
+             return task
 
          def update(self, id: int, mods):
-             """Update an item in the database.
+             """Update a task in the database.
 
              Args:
-                 id (int): The item id of an item.
-                 mods (Item): The modifications to be made to this item.
+                 id (int): The task id of a task.
+                 mods (Task): The modifications to be made to this task.
              """
              self._db.update(changes, doc_ids=[id])
 
          def delete(self, id: int):
-             """Deletes an item in the database.
+             """Deletes a task in the database.
 
              Args:
-                 id (int): The item id of an item.
+                 id (int): The task id of a task.
              """
              self._db.remove(doc_ids=[id])
 
          def close(self):
              """Closes the database connection."""
              self._db.close()
 
-  Then I would use :func:`dataclass` in :file:`src/items/api` to create an
-  :class:`Item` class:
+  Then I would use :func:`dataclass` in :file:`src/cusy/tasks/api` to create an
+  :class:`Task` class:
 
   .. code-block:: python
 
      from dataclasses import dataclass, field
 
 
      @dataclass
-     class Item:
+     class Task:
          summary: str = None
          owner: str = None
          state: str = "todo"
          id: int = field(default=None, compare=False)
 
 
-     class ItemsException(Exception):
+     class TasksException(Exception):
          pass
 
 
-     class ItemsDB:
+     class TasksDB:
          def __init__(self, db_path):
              self._db_path = db_path
-             self._db = DB(db_path, ".items_db")
+             self._db = DB(db_path, ".tasks_db")
 
-         def add_item(self, item: Item):
+         def add_task(self, task: Task):
              return
 
-         def get_item(self, item: Item):
+         def get_task(self, task: Task):
              return
 
-         def update_item(self, item: Item):
+         def update_task(self, task: Task):
              return
 
-         def delete_item(self, item: Item):
+         def delete_task(self, task: Task):
              return
 
          def close(self):
@@ -966,16 +967,16 @@ Checks
          def path(self):
              return self._db_path
 
-  :class:`ItemsException` Item and :class:`ItemsDB` are then provided in
-  :file:`src/items/__init__.py`:
+  :class:`TasksException` Task and :class:`TasksDB` are then provided in
+  :file:`src/cusy/tasks/__init__.py`:
 
   .. code-block:: python
 
-     from .api import ItemsException, Item, ItemsDB
+     from .api import TasksException, Task, TasksDB
 
   .. seealso::
-     You can find a complete example at `github.com/veit/items
-     <https://github.com/veit/items/>`_.
+     You can find a complete example at `github.com/veit/cusy.tasks
+     <https://github.com/veit/cusy.tasks/>`_.
 
 :doc:`/save-data/files-directories`
 -----------------------------------

docs/appendix/glossary.rst

@@ -8,7 +8,7 @@ Glossary
    User Acceptance Test
        Verification that software functions as intended from the user’s
        perspective and that users accept the software. Acceptance tests are
-       primarily used in :term:` Extreme Programming`.
+       primarily used in :term:`Extreme Programming`.
 
    Argument
        A value that is passed to a function. There are two types of arguments:
@@ -630,8 +630,11 @@ Glossary
           * :ref:`wheels`
 
    whey
-       Simple Python :term:`wheel` builder with automation options for
-       :term:`trove-classifiers`.
+       A simulated version of a class or method. It has a functional
+       implementation but uses a kind of shortcut, making it unsuitable for
+       production use. For example, an in-memory database might be used for
+       testing purposes but not in production. In this context, the in-memory
+       database would act as a fake.
 
    .. _end-packaging:
 
@@ -668,7 +671,7 @@ Glossary
        :doc:`/test/unittest`
            supports you in the automation of tests.
        :doc:`/test/mock`
-           allows you to create and use mock objects.
+           allows you to create and use :term:`Mock` objects.
        :doc:`../document/doctest`
            allows you to test tests written in Python :term:`docstrings
            <Docstring>`.
@@ -689,23 +692,41 @@ Glossary
        platforms.
 
    Dummy
-       Object that is passed around but never actually used. Normally dummies
-       are only used to fill :term:`parameter` lists.
+       An object that is passed along but is not intended for use in your tests.
+       It has no effect whatsoever on the behaviour of your tests. An example of
+       a dummy could be an attribute that is required to instantiate a class but
+       is not needed for the test.
 
    ``except``
        Keyword used to intercept an :term:`exception` and handle it carefully.
 
    Fake
-       Object that has an implementation that actually works, but usually takes
-       a shortcut that makes it unsuitable for production.
+       A simulated version of a class or method. It has a functional
+       implementation but uses a kind of shortcut, making it unsuitable for
+       production use. For example, an in-memory database might be used for
+       testing purposes but not in production. In this context, the in-memory
+       database would act as a fake.
 
    Integration test
        Tests that check whether the different parts of the software work
        together as expected.
 
    Mock
-       Objects programmed with :term:`exceptions <exception>` that form a
-       specification of the calls you are likely to receive.
+       A mock simulates attributes, classes and methods. This enables developers
+       to
+
+
+       * test certain aspects of their code more effectively
+       * test in a controlled environment
+       * test for external dependencies
+
+       Unlike :term:`stubs <Stub>`, a mock can be used not only to verify the
+       result, but also to check **how** the result was achieved or whether the
+       correct methods were called.
+
+       The Python library for mocks is :doc:`unittest.mock <../test/mock>`. It
+       is also supported by :doc:`../test/pytest/index`. Alternatively, however,
+       you can also use `pytest-mock <https://pypi.org/project/pytest-mock/>`_.
 
        .. seealso::
           * `Mock object <https://en.wikipedia.org/wiki/Mock_object>`_
@@ -720,30 +741,33 @@ Glossary
        Tests to protect against new errors or regressions that may occur as a
        result of new software and updates.
 
-   Stubs
-       provide ready-made responses to calls made during the test and usually
-       do not react at all to anything that has not been programmed for the
-       test.
+   Spy
+       Spies are used to wrap real objects and, by default, forward all method
+       calls to the original object. They therefore intercept all calls to a
+       real object and log them. This makes it possible to monitor calls to the
+       original object (for example, how often a particular method has been
+       called) without replacing the original object (as a :term:`mock` would
+       do, for instance).
+
+   Stub
+       A non-real object with pre-programmed behaviour. In most cases, stubs
+       simply return fixed values, known as *canned data*.
 
    Test-driven development
    TDD
-       A technique for creating software that guides software development by
+       A software development technique that guides the development process by
        writing tests. It was developed in the late 1990s by Kent Beck as part of
-       Extreme Programming. Essentially, it involves repeating three simple
-       steps:
+       :term:`Extreme Programming`. Essentially, it involves repeating three
+       simple steps:
 
        * Write a test for the next feature to be added.
        * Write the function code until the test passes.
-       * Refactor both the new and old code to make it well structured.
+       * Revise both the new and the old code to ensure it is well structured.
 
-       Although these three steps, often summarised as *‘red – green –
-       refactor’*, form the core of the process, there is also an important
-       first step, in which a list of test cases is created. One of these tests
-       is then selected, *‘Red – Green – Refactor’* is applied to it, and the
-       next test is selected. During the process, further tests are added to
-       this list.
+       These three steps are often summarised as *‘Red – Green – Refactor’*.
 
        .. seealso::
+          * :doc:`../test/tdd`
           * `Canon TDD <https://tidyfirst.substack.com/p/canon-tdd>`_ by Kent
             Beck
           * `Test-driven development by example

docs/document/sphinx/main.py

@@ -6,7 +6,7 @@
 app = FastAPI()
 
 
-class Item(BaseModel):
+class Task(BaseModel):
     name: str
     price: float
     is_offer: Optional[bool] = None
@@ -17,11 +17,11 @@ def read_root():
     return {"Hello": "World"}
 
 
-@app.get("/items/{item_id}")
-def read_item(item_id: int, q: Optional[str] = None):
-    return {"item_id": item_id, "q": q}
+@app.get("/cusy.tasks/{task_id}")
+def read_task(task_id: int, q: Optional[str] = None):
+    return {"task_id": task_id, "q": q}
 
 
-@app.put("/items/{item_id}")
-def update_item(item_id: int, item: Item):
-    return {"item_name": item.name, "item_id": item_id}
+@app.put("/cusy.tasks/{task_id}")
+def update_task(task_id: int, task: Task):
+    return {"task_name": task.name, "task_id": task_id}

docs/document/sphinx/main.py.orig

@@ -1,15 +1,12 @@
 from typing import Optional
-
 from fastapi import FastAPI
 
 app = FastAPI()
 
-
 @app.get("/")
 def read_root():
     return {"Hello": "World"}
 
-
-@app.get("/items/{item_id}")
-def read_item(item_id: int, q: Optional[str] = None):
-    return {"item_id": item_id, "q": q}
+@app.get("/cusy.tasks/{task_id}")
+def read_task(task_id: int, q: Optional[str] = None):
+    return {"task_id": task_id, "q": q}

docs/oop/dataclasses.rst

@@ -12,14 +12,14 @@ create such a class.
    matrices with numbers I use :doc:`Numpy
    <Python4DataScience:workspace/numpy/index>`.
 
-Let’s say we want to store a class that represents an item with ``summary``,
+Let’s say we want to store a class that represents a task with ``summary``,
 ``owner``, ``state`` and ``id``. We can define such a class with:
 
 .. code-block:: pycon
 
    >>> from dataclasses import dataclass
    >>> @dataclass
-   ... class Item:
+   ... class Task:
    ...     summary: str = None
    ...     owner: str = None
    ...     state: str = "todo"
@@ -32,30 +32,30 @@ If I display the instance of the class, I get the class name and the attributes:
 .. code-block:: pycon
 
    >>> i1
-   Item(summary='My first item', owner='veit', state='todo', id=1)
+   Task(summary='My first task', owner='veit', state='todo', id=1)
 
 In general, data classes are used as syntactic sugar for creating classes that
 store data. You can add extra functionality to your classes by defining methods.
-We will add a method to the class that creates an Item object from a
+We will add a method to the class that creates a Task object from a
 :doc:`Dict <../types/dicts>`:
 
 .. code-block:: pycon
 
    >>> @dataclass
-   ... class Item:
+   ... class Task:
    ...     ...
    ...     @classmethod
    ...     def from_dict(cls, d):
-   ...         return Item(**d)
+   ...         return Task(**d)
    ...
-   >>> item_dict = {
-   ...     "summary": "My first item",
+   >>> task_dict = {
+   ...     "summary": "My first task",
    ...     "owner": "veit",
    ...     "state": "todo",
    ...     "id": 1,
    ... }
-   >>> Item.from_dict(item_dict)
-   Item(summary='My first item', owner='veit', state='todo', id=1)
+   >>> Task.from_dict(task_dict)
+   Task(summary='My first task', owner='veit', state='todo', id=1)
 
 .. tip::
    `cusy seminar: Advanced Python