Contributing

Contributions are greatly appreciated. This page is here to describe how you can help us enhance Sakia wallet.

Code organization

Sakia has been conceived on a Model View Presenter pattern. We have 3 main modules containing different data :

• The core contains all the basic classes, these classes contains data and can work and start asynchronous background tasks. The logic of the software is contained here.
• The gui contains all the classes to display widgets to the user. This is where the interaction with the buttons are implemented. We try to put the less logic possible in these classes because testing widgets is hard.
• The models contains all the classes to display data in Qt lists and tables. These models are refresh, and when refreshed, they save all the informations needed to display statically.

The ui files are placed in res/ui. The python files generated from these files are placed in gen_resources module.

Writing code

We generally use Pycharm for development, but you can use whatever editor you prefer.
There are 3 importants points we want to respect :

• To write the docstrings of any method you write or modify. The docstrings need to describe the types of parameters and return values, the role of the method, and the role of the parameters.
• To respect the PEP8 principles. We would like to have 0 PEP8 warning in the source code of sakia.
• To test every method and classes created. Writing test for sakia is described in next chapter.

Writing tests

We write tests using unittest python official module. The tests are separated in two main modules :

• The unit module : The tests contained here are unit tests. They use massively mocking and magic mocking of objects. This is where we test mainly the core classes and methods.
• The functional module : The tests contained here are functional tests. They do not use mocking and magic mocking of objects. Instead, they mock ucoin nodes using the server mock in sakia.tests.mocks.server.py. In the module tests.mocks.bma you can find many already existing mocks of nodes to tests some specific community situations.

If your test needs an asynchronous loop, you need your class to inherit unittest.TestCase and QuamashTest. Just add the following calls to your setUp and tearDown methods :

• In setUp : self.setUpQuamash()
• In tearDown : self.tearDownQuamash()

If you need to mock a coroutine, use CoroutineMock from package asynctest.mock. For more informations about the package asynctest, please refer to its documentation.