Skip to content

Commit

Permalink
update docs
Browse files Browse the repository at this point in the history
  • Loading branch information
searscr committed Mar 6, 2024
1 parent 3d8a642 commit 02532fb
Show file tree
Hide file tree
Showing 7 changed files with 281 additions and 119 deletions.
124 changes: 124 additions & 0 deletions docs/source/Developer/Coding_standards.rst
Original file line number Diff line number Diff line change
@@ -0,0 +1,124 @@
.. _coding_standards:

============
Contributing
============

We welcome contributions to the project. Please read the following guidelines before
submitting a pull request.

All contributors agree to the following:
- You have permission and any required rights to submit your contribution.
- Your contribution is provided under the license of this project and may be redistributed as such.
- All contributions to this project are public.

All contributions must be
`"signed off" in the commit <https://git-scm.com/docs/git-commit#Documentation/git-commit.txt---signoff>`_
log and by doing so you agree to the above.

Getting access to the main project
----------------------------------

Direct commit access to the project is currently restricted to core developers.
All other contributions should be done through pull requests using the standard github mechanisms.

=============
Pull Requests
=============

* All pull requests should be made against the ``next`` branch.
* All changes made require associated tests and should follow :ref:`testing guidelines <testing>`.
* Developers should run the pre-commit hooks locally *before* submitting a pull request.
* Pull requests do not currently run the tests that require the garnet-data submodule. Developers should run these tests locally *before* submitting a pull request.
* If applicable, the pull request should include updates to the :ref:`documentation <documentation>`.
* All pull requests should include any information required to test the changes. This may include:

* A description of the changes
* A description of how to test the changes
* Any relevant data or scripts required to test the changes

A simple example of this workflow would be as follows:

.. code-block:: sh
git checkout -b my_new_feature
# Write Tests for your new feature
python -m pytest # New tests should fail
# Write code to make the tests pass
python -m pytest # All tests should pass
# update the documentation (if applicable)
git add <files>
git commit -m "My new feature" # pre-commit will run here
git push -u origin my_new_feature
Then, go to the `github page <https://github.com/neutrons/garnet/>`_ for the repository and create a new pull request from the ``my_new_feature`` branch to the ``next`` branch.

================
Coding Standards
================

A few notes on coding standards:

* Variable and function names should be descriptive and follow the ``lower_case_with_underscores`` convention.
* All code will be checked and formatted using `ruff <https://docs.astral.sh/ruff/rules/>`_.
* Docstrings should be used to document all functions, classes, and Modules.
* Pre-commit hooks are configured to run for every PR, and can be run locally on every commit.

Pre-commit
----------

Pre-commit is a tool that is used to ensure that all code is formatted and linted before being committed.

Install pre-commit
++++++++++++++++++

pre-commit can be installed using the following command:

.. code-block:: sh
pre-commit install
You should only need to do this once. pre-commit will now run on every commit.

Run pre-commit manually
+++++++++++++++++++++++

The following command will run pre-commit on all staged changes:

.. code-block:: sh
pre-commit
To run pre-commit on all files in the repository, run the following command:

.. code-block:: sh
pre-commit run --all
More information on pre-commit can be found in the `pre-commit documentation <https://pre-commit.com/>`_.


========================
Documentation Guidelines
========================

.. _documentation:

Updating the Documentation
--------------------------
This project uses `Sphinx <https://www.sphinx-doc.org/en/master/>`_ to generate documentation and is updated with every pull request.
The documentation is a combination of pages written in `reStructuredText <https://www.sphinx-doc.org/en/master/usage/restructuredtext/basics.html>`_ and
docstrings pulled from the code.
A simple guide to updating documentation in Garnet can be found `here <https://github.com/neutrons/garnet/blob/next/docs/README.md>`_.

Building the Documentation
--------------------------
To build the documentation locally, run the following commands from the root of the repository:

.. code-block:: sh
cd docs
make clean
make html
The documentation will be built in the ``docs/_build/html`` directory.
Original file line number Diff line number Diff line change
@@ -1,5 +1,6 @@
=============
GUI Standards
**************
=============

.. contents:: Table of Contents
:local:
Expand All @@ -9,7 +10,7 @@ GUI Standards


Validation Strategy
===================
*******************

GUI validation is a process aimed at ensuring the accuracy, functionality, and consistency of
the graphical elements within a software application's user interface. It involves systematically
Expand All @@ -31,7 +32,7 @@ code structure. We plan to create and implement these helper functions to optimi
process in our software development practices.

Validation Items
================
****************

Fields
######
Expand All @@ -42,7 +43,7 @@ example value can be added in fields the describe complex ideas (e.g. x,y,z). Th
will guide the users seamlessly through the data input process while ensuring clarity and
adherence to form submission requirements.

.. figure:: images/optional.png
.. figure:: ../images/optional.png
:align: center
:alt: Optional Fields

Expand All @@ -57,13 +58,13 @@ with no default values (text fields) will feature a light yellow background, ser
adopted convention to visually cue users. This combination of visual indication, through both
asterisks and background color enhances user experience.

.. figure:: images/required.png
.. figure:: ../images/required.png
:align: center
:alt: Required Fields

Required Field with asterisk and light yellow background.

.. figure:: images/req-w-default.png
.. figure:: ../images/req-w-default.png
:align: center
:alt: Required Field with default value

Expand All @@ -84,13 +85,13 @@ generic names like “Load”. If multiple buttons exist in the View, it should
use which input/output fields correspond to each button. This can be achieved through grouping
fields and clear labels.

.. figure:: images/button-disabled.png
.. figure:: ../images/button-disabled.png
:align: center
:alt: Button invalid

Button with meaningful name and disabled state.

.. figure:: images/button-enabled.png
.. figure:: ../images/button-enabled.png
:align: center
:alt: Button valid

Expand Down Expand Up @@ -123,13 +124,13 @@ adherence to specific ranges, ensures data integrity in user input. This validat
runs as data is entered and enables buttons to become active only when the entered data meets
predefined criteria.

.. figure:: images/1invalid.png
.. figure:: ../images/1invalid.png
:align: center
:alt: Field Validation

Field validation with red border and status bar message for one invalid field.

.. figure:: images/2invalid.png
.. figure:: ../images/2invalid.png
:align: center
:alt: Field Validation

Expand All @@ -146,27 +147,27 @@ may include multiple criteria and require more than a cursory check to ensure th
underlying algorithm's requirements. If validation fails, the execution halts, prompting
the user to update the failing values before proceeding.

.. figure:: images/novalidation.png
.. figure:: ../images/novalidation.png
:align: center
:alt: Data Input Validation

Data input validation will occur after the button has been enabled and pressed.

.. figure:: images/algo-fail-validation.png
.. figure:: ../images/algo-fail-validation.png
:align: center
:alt: Data Input Validation

If a field fails validation after the button has been invoked, a popup will appear to notify
user and the field will be marked.

.. figure:: images/red-until-after.png
.. figure:: ../images/red-until-after.png
:align: center
:alt: Data Input Validation

After failing validation, button remains enabled and the fields that failed validation
will be marked until the button is pressed again.

.. figure:: images/all-valid.png
.. figure:: ../images/all-valid.png
:align: center
:alt: Data Input Validation

Expand All @@ -193,7 +194,7 @@ with an error status, guiding users on how to proceed or address the issue. This
approach ensures a comprehensive error management system, promoting smoother application
functionality and facilitating efficient issue resolution.

.. figure:: images/error-popup.png
.. figure:: ../images/error-popup.png
:align: center
:alt: Error Handling

Expand Down
Original file line number Diff line number Diff line change
@@ -1,9 +1,9 @@

.. _MVP_Guidelines:

==========================
Model-View-Presenter (MVP)
==========================
=====================================
Model-View-Presenter (MVP) Guidelines
=====================================

Overview
========
Expand Down Expand Up @@ -94,15 +94,3 @@ Advantages
The clear separation of responsibilities makes the codebase more maintainable.
Changes in one component, such as the View or Model, do not directly impact the
others.

Usage
======

MVP is commonly used in GUI-based applications where a clear separation between
the user interface and business logic is crucial for maintainability and
testability.

.. note::

MVP is an evolution of the Model-View-Controller (MVC) pattern, addressing some of its limitations,
especially in terms of testing and code organization.
102 changes: 102 additions & 0 deletions docs/source/Developer/Testing_standards.rst
Original file line number Diff line number Diff line change
@@ -0,0 +1,102 @@
.. _testing:

=======
Testing
=======

The project contains testing infrastructure in the tests/ folder:
* data/ : It contains the test data. Small data files can be included in this
directory. For large data files, there is a subfolder garner-data that is connected to a gitlfs data
repo in gitlab as a submodule: https://code.ornl.gov/sns-hfir-scse/infrastructure/test-data/garnet-data
* tabs/ : Tests are organized into folders for every page:

* home/
* order_param/
* peak_integr/
* recp_space/
* ub_peak_find\/

In every page-tab directory the tests are furtherd arranged in MVP-based filesystem structure:

* models/
* views/
* presenter/

* utility/ : It contains tests for code elements that are shared among pages and belong to the corresponding file folder (utility/).
* workflows/ : It contains tests with code that span among pages to test full reduction workflows.

Writing Tests
`````````````
We strongly encourage adopting a Test-Driven Development (TDD) approach throughout the development process. By writing tests before implementing
features, we promote code reliability, maintainability, and faster debugging. Embrace TDD as a best practice to enhance the overall quality of our project.
The general approach is to write tests for every function and method in the code. The tests should cover all possible input combinations and edge cases.

The tests are written using the `pytest <https://docs.pytest.org/>`_ framework to allow for automated testing. The test files are named `test_*.py` and are
placed in the corresponding directory of the code they are testing.

Tests that use the garnet-data submodule, will need to be configured for github runners (TBD).
Additionally, the `pytest marker <https://docs.pytest.org/en/8.0.x/reference/reference.html#custom-marks>`_ ``datarepo`` is used to skip tests that require
garnet-data submodule to be present.

Running Tests
`````````````
The tests can be run using the `pytest <https://docs.pytest.org/>`_ framework. The tests can be run in the garnet conda environment.
The following instructions assume that the current working directory is the root of the garnet repository and that the garnet conda environment is activated.

To run all tests:

.. code-block:: sh
python -m pytest
To run a specific test:

.. code-block:: sh
python -m pytest path/to/test_file.py
To run a specific test function:

.. code-block:: sh
python -m pytest path/to/test_file.py::test_function
To run tests that require the garnet-data submodule:

.. code-block:: sh
python -m pytest -m datarepo
=====================
Testing a specific PR
=====================

Checkout to the PR by following the Pull-Request instructions:

.. code-block:: sh
conda activate <garnet_environment>
cd /path/to/my/local/garnet/repo/
git fetch origin pull/<PULL_REQUEST_NUMBER>/head:pr<PULL_REQUEST_NUMBER>
git switch pr<PULL_REQUEST_NUMBER>
#run tests
python -m pytest <item_to_test>
#and/or start garnet
garnet
To test a specific Mantid build and/or version in another conda environment, garnet can be installed in that environment:

.. code-block:: sh
conda activate <mantid_environment>
#in case of a mantid build, else skip
./bin/AddPythonPath.py
cd /path/to/my/local/garnet/repo/
git fetch origin pull/<PULL_REQUEST_NUMBER>/head:pr<PULL_REQUEST_NUMBER>
git switch pr<PULL_REQUEST_NUMBER>
python -m pip install -e .
#run tests
python -m pytest <item_to_test>
#and/or start garnet
garnet
Loading

0 comments on commit 02532fb

Please sign in to comment.