For unit tests I usually have a test/ folder next to my src/ folder, that duplicates the folder structure. My brain prefers things being seperate from eachother (resources, source code per language, tests) and this is afaik the only way that you can keep it consistent between different languages (C# for example needs a seperate unit test project)
In Rust, the tests usually sit right next to the source code, even in the same file. That’s partly because the compiler can just strip the tests from the final binary, and I assume partly just conventional. In Python, you usually want to keep the tests out of the final sdist/wheel, so the setup you described is probably the most common in bigger projects.
In production!
I kid I kid.
For unit tests, I put them within a folder parallel to the source code. The directory in that folder matches the module hierarchy.
A flat structure can work for extremely small projects, but things start to go sideways as the code base grows.
Putting the test files alongside the source files makes it harder work with from a project management perspective:
pytest
has to check more files when doing discovery, which makes the tests take longer- It is significantly harder to configure
mypy
to a more lenient set of rules for test code. - It is harder to package/deploy only the runtime code
If the project is big enough to have integration tests, I prefer to have those in their own folder like the unit test folder. It is possible to mark tests into different categories, but putting them in a dedicated folder makes it is harder for people to forget to mark an integration test.
Side note, I hadn't tried mypy
until your reply mentioned it and made me curious. I love it, and have already integrated it into my editor and pipeline. Thanks!
My projects are usually laid out like this at work:
src/
— module_1/
— some_file.py
test/
— module_1/
— some_file_test.py
I just copy the Java dev structure for this.
Which is basically just a reflection of directories. Someone else mentioned it here.
Tests?
In an iPython terminal if I think of doing some, but I do want to implement something more formal soon.
Python
Welcome to the Python community on the programming.dev Lemmy instance!
📅 Events
Past
November 2023
- PyCon Ireland 2023, 11-12th
- PyData Tel Aviv 2023 14th
October 2023
- PyConES Canarias 2023, 6-8th
- DjangoCon US 2023, 16-20th (!django 💬)
July 2023
- PyDelhi Meetup, 2nd
- PyCon Israel, 4-5th
- DFW Pythoneers, 6th
- Django Girls Abraka, 6-7th
- SciPy 2023 10-16th, Austin
- IndyPy, 11th
- Leipzig Python User Group, 11th
- Austin Python, 12th
- EuroPython 2023, 17-23rd
- Austin Python: Evening of Coding, 18th
- PyHEP.dev 2023 - "Python in HEP" Developer's Workshop, 25th
August 2023
- PyLadies Dublin, 15th
- EuroSciPy 2023, 14-18th
September 2023
- PyData Amsterdam, 14-16th
- PyCon UK, 22nd - 25th
🐍 Python project:
- Python
- Documentation
- News & Blog
- Python Planet blog aggregator
💓 Python Community:
- #python IRC for general questions
- #python-dev IRC for CPython developers
- PySlackers Slack channel
- Python Discord server
- Python Weekly newsletters
- Mailing lists
- Forum
✨ Python Ecosystem:
🌌 Fediverse
Communities
- #python on Mastodon
- c/django on programming.dev
- c/pythorhead on lemmy.dbzer0.com
Projects
- Pythörhead: a Python library for interacting with Lemmy
- Plemmy: a Python package for accessing the Lemmy API
- pylemmy pylemmy enables simple access to Lemmy's API with Python
- mastodon.py, a Python wrapper for the Mastodon API