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`. They 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 you 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](http://asynctest.readthedocs.org/en/latest/).
