It’s hard to keep the right balance between showing code and showing testing that is a bit more complex to make interesting on stream. That’s why I jumped to some actual implementation before finishing the complete test setup.
In this blog post, I’ll explain how I setup the unit testing as well code quality checks in the project. Obviously currently the tests are all failing, and that’s expected, as no mocking mechanism was implemented yet in the unit testing of the project, and that’s where we will head on the next stream.
Setup.py
The setup.py file is the main part on how to define the project
I’ll quickly go over the descriptions parts to give details on the technical parts of this file, note that to ensure code security, it’s recommended to put the setup details in the setup.cfg file instead, and I’ll move most of the information to this part in the future.
package_dir and packages
These 2 parts are defining what packages will be deployed with the install. They are not really important in our case as this part of the project won’t be deployed on a real machine, but it will be used to run CDK to perform the deployment in the designated AWS account.
package_dir is a mapping of root package name to their root directories.
Let’s imagine a tree like:
- src
- package1
- package2
- src2
- package3
if you want to use packages in all theses directories you can use:
package_dir = {
"myproject": "src",
"mysideproject": "src2"
},
packages = ["myproject.package1", "myproject.pacakge2", "mysideproject.packages3"],to import all your packages, not that it’s expected that packages contains an __init__.py file.
I’ll have to do more digging in there, but I should be pretty help full to host both packages and stubber in a single project to ensure that both are synchronized at anytime. Still not sure I’ll really need to dig on this
This is a setup for more complex projects, in our case I used:
packages=setuptools.find_packages(where="src")to auto import all the packages in the src directory
install_requires and test_requires
These 2 part contains the requirements for respectively not much to say here, it’s a list of dependencies, following the “package[<op>version]” syntax.
setup.cfg
As I said, most of the configuration set in setup.py can be handled in setup.cfg. It is best practice to use it whenever possible to prevent arbitrary code execution while using setuptools.
It can contains more information such as other tools such as unittests, coverage, type checker and code style checkers.
tox.ini
This is our main game, this file allows to define all the tools we want to run through, as well as multiple environment, we can choose to run our tests in many version of python, to ensure it work well on all the version we promise.
An important point on which I struggled a bit was the missing import issue, to ensure you don’t bump into this issue ensure to add ‘-rrequirements.txt’ in the testenv/deps list.
Other thoughts:
This whole project is not going as smoothly as I expected, coding on stream is a real exercise on its own, I’ve already saw many implementation issues, that would draw me back to the conceptions board on other circumstances, but nothing too complex to redo at the end of the implementation at the DRY step.
For now I’ll accept this technical debt to make the project go on as those issues are not relevant to streaming part of the project. It will be rework after this project reached the end of the stream content to make it usable, I’ll take a couple of weeks to do this rework off stream.
Another point is as I said, and that’s something I’m quite aware of, streaming is exhausting, and streaming while doing technical stuff even more, it’s really hard to make interesting but it’s also a growing experience for me to help me we where I want to go on this content creation adventure.
0 Replies to “Password Store – More testing ahead”