Lessons Learned during the developtmen of `corssfire` Python package

Sat, 30 Mar 2024 00:00:00 +0000

The crossfire package was first developed in 2021, during the #Hacktoberfest. Since this first version I have recieved support from @cuducos. Last year, the crossfire API was updated, and thus the package should be updated as well. Again, I asked for Cuducos’ help, and he kindly accepted to mentor me during the development of the new version of the package. This time, I can see that I have learned a lot of things that I would like to share here, in a not so structured form…. My idea here is to write down some thoughts, notes, and comments about the process of developing the package.

Debuging in test

I already knew about the importance of debugging, althought I never used it. But something that I didn’t know is that I could debug the test, also. This can be done by importing pytest to the source code, and adding pytest.set_trace() before the line that I want to debug. Then, we can run the test with the -k parameter, which will run only the test that I want to debug.

poetry run pytest -k test_client_load_states

The set_trace makes the test stop and leave the terminal so we can call the objects and functions to confirm if they are as expected.

here (in Pt-Br)

TDD is about exploring issues rather than a solution

At some point during the package development, I was facing an issue when trying to set a return value for a mocked function. After a long time analysing my code and not identifying the issue, I found in Stack Over Flow (yes, I still using it :) a suggestion of setting the autospec parameter to True. Of course I looked up at the pytest documentation to [try to] understand what does it do, but all I got was some glue about it. I decided, anyway, to use it and commit the code beliving I have solved [apparently] the issue. So, then, Cuducos adviced me:

Ok, so never add code you don’t understand. Never. You can use it to ask: hey, I noticed that when I add that, it works for you. But this is a way to explore the issue rather than a solution. (@cuducos) here

Flat path to success

o flat path to success foi mencionado no processo de revisão do código e básicamente se refere a:

escrever o código de forma clara e direta, evitando aninhamentos e complexidades, onde o propósito principal do código é facilmente discernível sem mergulhar em estruturas aninhadas.

Instalando versão pacote Python a partir do GitHub

No processo de desenvolvimento é importante sempre testar o código em um ambiente diferente daquele no qual se está desenvolvendo a solução. Para isso, podemos instalar a versão do pacote diretamente do GitHub, especificando a branch a ser usada, conforme o exemplo abaixo.

pip install git+https://github.com/username/repo.git@branch_name

En |

Lessons Learned during the developtmen of `corssfire` Python package

Debuging in test

TDD is about exploring issues rather than a solution

Flat path to success

Instalando versão pacote Python a partir do GitHub