Refactor Jupyter magic unit tests

[noklam]

Description

Close #3585

• Refactor jupyter magic unit tests with conftest #3585

Development notes

It seems like a lot of changes but the main change is I use "real" dummy function instead of string, as a result a lot of mocking and function literals are not needed anymore.

1. Move all those dummy function and dummy function literal (the text of the function) to a separate file. In fact I removed the literal because I can actually use the inspect the module to get it
2. To use inspect, I need to import it as a module, so the package need to exist, I use logging as the dummy library to replace all package1, package2 etc. We can also mock this but in my experience mocking import will mess up with pytest. This give me the benefit that I don't need to have a lot of """xxxxxx""", instead I just import the real module and retrieve the information from inspect.
3. Remove all unnecessary mocking because the module is now importable.

Bonus: _prepare_function_body is now basically identical to inspect.getsourcefiles, so there isn't much to test. We can remove the tests if we want, otherwise it can stay in case we change the implementation in the future.

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

[AhdraMeraliQB]

This is so much easier to follow! 🌟

[SajidAlamQB]

This is much cleaner and easier to read, awesome work @noklam! 👍

[SajidAlamQB]

Why are we using logging now?

[noklam]

@SajidAlamQB I have updated this in the PR and it is included in the PR description. In short, this python module need to be importable. The original code use package1,package2 which are not real package, as a result we need to do many mocking.

I choose logging for 2 reasons, 1. it's in standard libraries so no extra dependencies (can be any other standard libraries), 2. It has sub-module so I can test for different kind of import statements. You may swap logging with os and it will do the same job.