|
| 1 | +.. |
| 2 | + Licensed to the Apache Software Foundation (ASF) under one |
| 3 | + or more contributor license agreements. See the NOTICE file |
| 4 | + distributed with this work for additional information |
| 5 | + regarding copyright ownership. The ASF licenses this file |
| 6 | + to you under the Apache License, Version 2.0 (the |
| 7 | + "License"); you may not use this file except in compliance |
| 8 | + with the License. You may obtain a copy of the License at |
| 9 | +
|
| 10 | + http://www.apache.org/licenses/LICENSE-2.0 |
| 11 | + |
| 12 | + Unless required by applicable law or agreed to in writing, |
| 13 | + software distributed under the License is distributed on an |
| 14 | + "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY |
| 15 | + KIND, either express or implied. See the License for the |
| 16 | + specific language governing permissions and limitations |
| 17 | + under the License. |
| 18 | + |
| 19 | +============================== |
| 20 | +Testing Apache Hamilton code |
| 21 | +============================== |
| 22 | + |
| 23 | +A common question on `Slack <https://join.slack.com/t/hamilton-opensource/shared_invite/zt-2niepkra8-DGKGf_tTYhXuJWBTXtIs4g>`_ |
| 24 | +is "how do I test my Hamilton functions?" -- often with a worry that decorators |
| 25 | +will get in the way. The good news: a Hamilton function is just a Python |
| 26 | +function, so the standard ``pytest`` patterns you already know apply directly. |
| 27 | + |
| 28 | +This guide walks through four cases, in order of increasing scope: |
| 29 | + |
| 30 | +1. Unit-testing a plain function. |
| 31 | +2. Unit-testing a decorated function. |
| 32 | +3. Integration-testing the full DAG with the ``Driver``, including |
| 33 | + ``inputs=`` and ``overrides=``. |
| 34 | +4. Driving an in-memory module for self-contained tests (e.g. of custom |
| 35 | + materializers). |
| 36 | + |
| 37 | +The complete runnable code lives in |
| 38 | +`examples/testing <https://github.com/apache/hamilton/tree/main/examples/testing>`_. |
| 39 | +Every code block on this page is a ``literalinclude`` from that folder, so the |
| 40 | +docs and the example can never drift out of sync. |
| 41 | + |
| 42 | +Prerequisites |
| 43 | +------------- |
| 44 | + |
| 45 | +Install the example's dependencies and run it: |
| 46 | + |
| 47 | +.. code-block:: bash |
| 48 | +
|
| 49 | + cd examples/testing |
| 50 | + pip install -r requirements.txt |
| 51 | + pytest |
| 52 | +
|
| 53 | +You should see all 13 tests pass. |
| 54 | + |
| 55 | +1. Unit-testing plain functions |
| 56 | +------------------------------- |
| 57 | + |
| 58 | +Hamilton encourages you to put your transformation logic in ordinary modules |
| 59 | +that don't import the Driver. That makes them trivial to unit-test: |
| 60 | + |
| 61 | +.. literalinclude:: ../../examples/testing/my_functions.py |
| 62 | + :language: python |
| 63 | + :lines: 18- |
| 64 | + :caption: ``examples/testing/my_functions.py`` |
| 65 | + |
| 66 | +Tests are just calls to the function: |
| 67 | + |
| 68 | +.. literalinclude:: ../../examples/testing/test_my_functions.py |
| 69 | + :language: python |
| 70 | + :lines: 18- |
| 71 | + :caption: ``examples/testing/test_my_functions.py`` |
| 72 | + |
| 73 | +Notes |
| 74 | +^^^^^ |
| 75 | + |
| 76 | +* No Driver is required. You import the module under test and call its |
| 77 | + functions like any other Python code. |
| 78 | +* ``pytest.mark.parametrize`` is a clean way to cover edge cases without |
| 79 | + copy-pasting test bodies. |
| 80 | +* Use ``pd.testing.assert_series_equal`` (or ``assert_frame_equal``) for |
| 81 | + pandas outputs -- it gives readable diffs on failure. |
| 82 | + |
| 83 | +2. Unit-testing decorated functions |
| 84 | +----------------------------------- |
| 85 | + |
| 86 | +Hamilton's function modifiers (``@tag``, ``@parameterize``, ``@extract_columns``, |
| 87 | +...) tell Hamilton how to wire the function into the DAG. They do **not** |
| 88 | +change what the function does when you call it directly. You can therefore |
| 89 | +mix two complementary techniques: |
| 90 | + |
| 91 | +A. Call the underlying function in a unit test (cheap, fast). |
| 92 | +B. Build a Driver and assert on the expanded DAG, to verify the wiring (slower, |
| 93 | + but the only way to catch decorator misuse). |
| 94 | + |
| 95 | +The decorated module: |
| 96 | + |
| 97 | +.. literalinclude:: ../../examples/testing/decorated_functions.py |
| 98 | + :language: python |
| 99 | + :lines: 18- |
| 100 | + :caption: ``examples/testing/decorated_functions.py`` |
| 101 | + |
| 102 | +The tests: |
| 103 | + |
| 104 | +.. literalinclude:: ../../examples/testing/test_decorated_functions.py |
| 105 | + :language: python |
| 106 | + :lines: 18- |
| 107 | + :caption: ``examples/testing/test_decorated_functions.py`` |
| 108 | + |
| 109 | +3. Integration-testing the DAG |
| 110 | +------------------------------ |
| 111 | + |
| 112 | +For end-to-end tests, build a Driver from the module(s) under test and call |
| 113 | +``execute(...)`` with controlled inputs. |
| 114 | + |
| 115 | +Two arguments are especially useful: |
| 116 | + |
| 117 | +* ``inputs=`` injects test data at the **inputs** of the DAG -- the parameter |
| 118 | + names that aren't produced by any function. |
| 119 | +* ``overrides=`` short-circuits an **intermediate** node by pinning its value. |
| 120 | + This is the integration-test sweet spot: instead of fabricating realistic |
| 121 | + raw inputs and re-deriving every intermediate, hand the DAG a known value |
| 122 | + for ``spend`` (or any other node) and assert on the *downstream* logic. |
| 123 | + |
| 124 | +.. literalinclude:: ../../examples/testing/test_driver.py |
| 125 | + :language: python |
| 126 | + :lines: 18- |
| 127 | + :caption: ``examples/testing/test_driver.py`` |
| 128 | + |
| 129 | +Tip: ``Driver`` exposes a number of inspection methods -- |
| 130 | +``what_is_upstream_of``, ``what_is_downstream_of``, ``list_available_variables`` |
| 131 | +-- that are handy for asserting on graph shape, not just values. |
| 132 | + |
| 133 | +4. In-memory modules for self-contained tests |
| 134 | +--------------------------------------------- |
| 135 | + |
| 136 | +Sometimes you want a test that defines its own tiny Hamilton module inline |
| 137 | +-- to exercise a custom materializer, regression-test a data-quality bug, |
| 138 | +or demonstrate a pattern in a doctest. You don't need to create a new |
| 139 | +``.py`` file; ``hamilton.ad_hoc_utils.create_temporary_module`` packages |
| 140 | +inline-defined functions into a real module that the Driver can consume: |
| 141 | + |
| 142 | +.. literalinclude:: ../../examples/testing/test_ad_hoc_module.py |
| 143 | + :language: python |
| 144 | + :lines: 18- |
| 145 | + :caption: ``examples/testing/test_ad_hoc_module.py`` |
| 146 | + |
| 147 | +This is also how Hamilton itself tests several of its built-in materializers, |
| 148 | +so it scales up to fairly involved scenarios. See |
| 149 | +`tests/test_ad_hoc_utils.py <https://github.com/apache/hamilton/blob/main/tests/test_ad_hoc_utils.py>`_ |
| 150 | +in the Hamilton source for more usage examples. |
| 151 | + |
| 152 | +Where to go from here |
| 153 | +--------------------- |
| 154 | + |
| 155 | +* Read the :doc:`/concepts/best-practices/code-organization` page -- the |
| 156 | + module structure it recommends is the same one that makes tests easy to |
| 157 | + write. |
| 158 | +* Browse the |
| 159 | + `Hamilton test suite <https://github.com/apache/hamilton/tree/main/tests>`_ |
| 160 | + for ideas; the same patterns work for user code. |
| 161 | +* Have a testing pattern that isn't covered here? Share it on |
| 162 | + `Slack <https://join.slack.com/t/hamilton-opensource/shared_invite/zt-2niepkra8-DGKGf_tTYhXuJWBTXtIs4g>`_ |
| 163 | + -- we'd love to add it. |
0 commit comments