DOC Adding more details on how to contribute to the library

CONTRIBUTING.rst

@@ -126,6 +126,12 @@ Setting up the environment
 
 Follow the steps in the :ref:`installation_instructions` > "From Source" section to
 set up your environment.
+Make sure that pre-commit hooks are enabled, and run the test suite:
+
+.. code:: console
+
+   pytest -s skrub/tests
+
 
 When starting to work on a new issue, it's recommended to create a new branch:
 
@@ -162,6 +168,76 @@ Once you have pushed your commits to your remote repository, you can submit
 a PR by clicking the "Compare & pull request" button on GitHub,
 targeting the skrub repository.
 
+Testing the code
+~~~~~~~~~~~~~~~~
+
+Tests for files in a given folder should be located in a sub-folder
+named ``tests``: tests for Skrub objects are located in ``skrub/tests``,
+tests for the dataframe API are in ``skrub/_dataframe/tests`` and so on.
+
+Tests should check all functionalities of the code that you are going to
+add. If needed, additional tests should be added to verify that other
+objects behave correctly.
+
+Consider an example: your contribution is for the
+``AmazingTransformer``, whose code is in
+``skrub/_amazing_transformer.py``. The ``AmazingTransformer`` is added
+to as one of the default transformers for ``TableVectorizer``.
+
+As such, you should add a new file testing the functionality of
+``AmazingTransformer`` in ``skrub/tests/test_amazing_transformer.py``,
+and update the file ``skrub/tests/test_table_vectorizer.py`` so that it
+takes into account the new transformer.
+
+Additionally, you might have updated the dataframe API in
+``skrub/_dataframe/_common.py`` with a new function,
+``amazing_function``. In this case, you should also update
+``skrub/_dataframe/tests/test_common.py`` to add a test for the
+``amazing_function``.
+
+Run your tests using ``pytest``:
+
+.. code:: sh
+
+   pytest skrub/tests/test_amazing_transformer.py
+
+All tests should pass before submitting the code.
+
+Checking coverage on the local machine
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Checking coverage is one of the operations that is performed after
+submitting the code. As this operation may take a long time online, it
+is possible to check whether the code coverage is high enough on your
+local machine.
+
+First, run your tests with the ``--cov`` argument:
+
+.. code:: sh
+
+   pytest skrub/tests/test_amazing_transformer.py --cov=skrub
+
+This will create a ``.coverage`` file in the main folder, that can be
+converted to html with
+
+.. code:: sh
+
+   coverage html
+
+This will create the folder ``htmlcov``: by opening
+``htmlcov/index.html`` it is possible to check what lines are covered in
+each file.
+
+Updating doctests
+~~~~~~~~~~~~~~~~~
+
+If you alter the default behavior of an object, then this might affect
+the docstrings. Check for possible problems by running
+
+.. code:: sh
+
+   pytest --doctest-modules skrub/path/to/file
+
 
 Integration
 ^^^^^^^^^^^
@@ -199,6 +275,20 @@ actions are taken.
 Note that by default the documentation is built, but only the examples that are
 directly modified by the pull request are executed.
 
+- If the remote repository was changed, you might need to run
+  ``pre-commit run --all-files`` to make sure that the formatting is
+  correct.
+- If a specific test environment fails, it is possible to run the tests
+  in the environment that is failing by using pixi. For example if the
+  env is ``ci-py309-min-optional-deps``, it is possible to replicate it
+  using the following command:
+
+.. code:: sh
+
+   pixi run -e ci-py309-min-optional-deps  pytest skrub/tests/path/to/test
+
+
+
 Building the documentation
 --------------------------