Document best practices for writing tests for nodes and pipelines

[AhdraMeraliQB]

Description

Addresses #1271

Added the page "Test a Kedro project" to the spaceflights tutorial. The page details the structure of writing a positive and negative unit test for a node function, and an integration test for (part of) a pipeline, with examples. It then discusses some best practices for testing, including the directory setup, naming conventions, and use of fixtures.

The page on automated testing was updated to reflect the test directory structure we use in our template projects, and to include instructions on locally installing the Kedro project before testing, resolving the issues seen around imports from the project into the tests - xref on Slack

These changes will need to be updated on starters (PR paused - pending docs approval) - kedro-org/kedro-starters#216

Development notes

See the built docs here

The example tests have been tested in a spaceflights project (both unrefined and refactored versions) and pass as expected. These docs have pulled inspiration from some of the internal pages linked on the original issue.

Developer Certificate of Origin

We need all contributions to comply with the Developer Certificate of Origin (DCO). All commits must be signed off by including a Signed-off-by line in the commit message. See our wiki for guidance.

If your PR is blocked due to unsigned commits, then you must follow the instructions under "Rebase the branch" on the GitHub Checks page for your PR. This will retroactively add the sign-off to all unsigned commits and allow the DCO check to pass.

Checklist

• Read the contributing guidelines
• Signed off each commit with a Developer Certificate of Origin (DCO)
• Opened this PR as a 'Draft Pull Request' if it is work-in-progress
• Updated the documentation to reflect the code changes
• Added a description of this change in the RELEASE.md file
• Added tests to cover my changes
• Checked if this change will affect Kedro-Viz, and if so, communicated that with the Viz team

[astrojuanlu]

Thanks a lot for putting this together @AhdraMeraliQB !

I gave a very quick first pass

[astrojuanlu]

Other than a minor formatting comment and another one that probably should become an issue in itself, this looks great ⭐

[astrojuanlu]

Maybe let's use native MyST syntax

Suggested change

	>**NOTE**: The option `-e` installs an editable version of your project, allowing you to make changes to the project files without needing to re-install them each time.
	:::{note}
	The option `-e` installs an editable version of your project, allowing you to make changes to the project files without needing to re-install them each time.
	:::

https://myst-parser.readthedocs.io/en/latest/syntax/admonitions.html

(fenced admonitions should also work)

[AhdraMeraliQB]

The MyST syntax doesn't seem to render properly on RTD. Additionally, the syntax of >**NOTE** is currently consistent across the docs - I'm unsure of the motivation to change it

[astrojuanlu]

True, we needed the colon_fence extension

[ankatiyar]

Looks good to me! Thanks @AhdraMeraliQB 💯

[merelcht]

"we test the that outputs of the data science pipeline are those that are expected", at the moment we don't do this, but test that the pipeline runs without errors, that's why you needed to add the trivial assert statement. I think it would be better if we could indeed check some sort of output, even if it's just a logging statement.

[merelcht]

This looks great! Thanks @AhdraMeraliQB ✨

[merelcht]

👍