Fix: add initial tests content to guide

ENH: fixes from Jonny's review

Fix: review edits from Jonny p2

Fix: typos and cleanup

Fix: add example to tests ci page

Author: lwasser

_static/pyos.css

@@ -413,4 +413,4 @@ td,
 th {
   border: 1px solid #ccc; /* Light gray border */
   padding: 8px; /* Add some padding for better readability */
-}
+}

_templates/header.html

@@ -0,0 +1,6 @@
+<!-- custom head content-->
+<link rel="preconnect" href="https://fonts.googleapis.com">
+<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
+<link href="https://fonts.googleapis.com/css2?family=Itim&family=Poppins:wght@300;400;600&display=swap" rel="stylesheet">
+
+<!-- END custom head content -->

ci-tests-data/ci.md

@@ -0,0 +1,66 @@
+# What is continuous integration?
+
+When you’re ready to publish your code online, you can setup Continuous Integration (CI). CI is a platform that allows you to specify and run jobs or workflows that you define.
+These workflows include:
+
+- Running your test suite
+- Running code checkers / linters / spellcheck
+- Building your documentation
+- Deploying your documentation to GitHub pages
+
+CI also allows you to automate running workflows across a suite of environments including:
+
+- environments containing different Python versions and
+- different operating systems (Mac, Linux, Unix).
+
+### What is Continuous Deployment (CD)?
+
+Continuous deployment (CD) extends the CI process by automating the deployment of code changes to production or staging environments. In the case of your open source tool, CD can be used to:
+
+- Automate publishing to PyPI
+- Automate publishing your documentation to github pages or Read the Docs.
+
+It is also used once your conda-forge recipe is set up to keep your package up to date on conda-forge.
+
+### Why Use CI
+
+CI can be configured to run a workflow on every commit pushed to GitHub and every pull request opened. This ensures that any changes made to your package are tested across environments before they are merged into the main branch of your code.
+
+These checks are particularly useful if someone new is contributing to your code. Every change a contributor makes will be tested when it’s pushed to your code repository.
+
+Together, CI and CD streamline the process of building, testing, and deploying code. They aim to improve the efficiency, quality, and reliability of software development and publication.
+
+```{note}
+All pyOpenSci packages must use some form of continuous integration. Even if you are not planning to go through peer review, we strongly recommend that you use continuous integration too!
+```
+
+In the case of GitHub actions (which we will focus on here), CI workflows are running on online servers that support GitHub.
+
+## CI / CD Platforms
+
+There are numerous platforms available for CI/CD. Here, we will focus on GitHub Actions (GHA) which is built into GitHub. GitHub is the most commonly used platform to store scientific open source software.
+
+:::{note}
+If you are using GitLab CI/CD many of the principles described here will apply, however the workflow files may look different.
+:::
+
+### If you aren't sure, use GitHub Actions
+
+While you are welcome to use the continuous integration platform of your choice,
+we recommend Github actions because it is free-to-use and integrated tightly
+into the GitHub user interface. There is also an entire store of GitHub action
+templates that you can easily use and adapt to your own needs.
+
+:::{admonition} Other platforms that you may run into
+:class: info
+
+- [Appveyor:](https://www.appveyor.com/) used to be a goto for running tests on Windows operating systems until GitHub actions evolved to support Windows. AppVeyor has evolved to support other operating systems since Microsoft acquired GitHub.
+- [Travis CI:](https://www.travis-ci.com/) Used to be the most common CI platform used in our ecosystem until they dropped free support for open source.
+- [CircleCI:](https://circleci.com/) You will still see some people using CircleCI for specific tasks. CircleCi can be useful for automated builds of websites and documentation allowing you to preview the changes to that website in your browser.
+  :::
+
+## Embrace automation
+
+By embracing CI/CD, you can ensure that your code runs as you expect it to across the diverse landscapes of user environments. Further you can
+automate certain checks (and in some cases code fixes) including linting and code style. You can even automate spell checking your documentation
+and docstrings!

ci-tests-data/code-cov.md

@@ -0,0 +1,13 @@
+# Code coverage
+
+Code coverage is the amount of your package's codebase that is run as a part of running your project's tests. A good rule of thumb is to ensure that every line of your code is run at least once during testing. However, note that good code coverage does not guarantee that your package is well-tested. For example, you may run all of your lines of code, but not account for many edge-cases that users may have. Ultimately, you should think carefully about the way your package will be used, and decide whether your tests adequately cover all of that usage.
+
+A common service for analyzing code coverage is [codecov.io](https://codecov.io/). This project is free for open source tools, and will provide dashboards that tell you how much of your codebase is covered during your tests. We recommend setting up an account, and using codecov to keep track of your code coverage.
+
+```{figure} ../images/code-cov-stravalib.png
+:height: 450px
+:alt: Screenshot of the code cov service - showing test coverage for the stravalib package. in this image you can see a list of package modules and the associated number of lines and % lines covered by tests. at the top of the image you can see what branch is being evaluated and the path to the repository being shown.
+
+the Code cov platform is a useful tool if you wish to visually track code coverage. Using it you can not only get the same summary information that you can get with **pytest-cov** extension. You can also get a visual representation of what lines are covered by your tests and what lines are not covered. Code cove is mostly useful for evaluating unit tests and/or how much of your package code is "covered. It however will not evaluate things like integration tests and end-to-end workflows. b
+
+```

ci-tests-data/data.md

@@ -0,0 +1 @@
+# Data for packaging

ci-tests-data/index.md

@@ -0,0 +1,93 @@
+# Tests and data for your Python package
+
+In this section you will learn more about the importance of writing
+tests for you Python package.
+
+::::{grid} 1 1 2 2
+:class-container: text-center
+:gutter: 3
+
+:::{grid-item-card}
+:link: write-tests
+:link-type: doc
+
+✨ Why write tests ✨
+^^^
+
+Learn more about the art of writing tests for your Python package.
+Learn about why you should write tests and how they can help you and
+potential contributors to your project.
+:::
+
+:::{grid-item-card}
+:link: test-types
+:link-type: doc
+
+✨ Types of tests ✨
+^^^
+There are three general types of tests that you can write for your Python
+package: unit tests, integration tests and end-to-end (or functional) tests. Learn about all three.
+:::
+
+:::{grid-item-card}
+:link: run-tests
+:link-type: doc
+
+✨ How to Run Your Tests ✨
+^^^
+
+Learn more about what tools you can use to run tests. And how to run your
+tests on different Python versions and different operating systems both on
+your computer and using continuous integration on GitHub (or in any other CI).
+:::
+
+:::{grid-item-card}
+:link: data
+:link-type: doc
+
+✨ Package data ✨
+^^^
+This section is current in progress... link coming soon
+:::
+
+:::{grid-item-card}
+:link: ci
+:link-type: doc
+
+✨ Continuous Integration ✨
+^^^
+Learn what Continuous Integration is and how you can set it up to run tests, build documentation and publish your package to PyPI.
+:::
+::::
+
+```{toctree}
+:hidden:
+:maxdepth: 2
+:caption: Create & Run Tests
+
+Intro <self>
+Write tests <write-tests>
+Test types <test-types>
+Run tests <run-tests>
+Code coverage <code-cov>
+
+```
+
+```{toctree}
+:hidden:
+:maxdepth: 2
+:caption: Continuous Integration
+
+Intro to CI <ci>
+Run tests in CI <tests-ci>
+
+```
+
+```{toctree}
+:hidden:
+:maxdepth: 2
+:caption: Package data
+
+Package data <data>
+
+```