Fix: edits from @namurphy

Co-authored-by: Nick Murphy <[email protected]>

Update ci-tests-data/ci.md

Co-authored-by: Nick Murphy <[email protected]>

Update ci-tests-data/ci.md

Co-authored-by: Nick Murphy <[email protected]>

Update ci-tests-data/ci.md

Co-authored-by: Nick Murphy <[email protected]>

Update ci-tests-data/ci.md

Co-authored-by: Nick Murphy <[email protected]>

Update ci-tests-data/ci.md

Co-authored-by: Nick Murphy <[email protected]>

Update ci-tests-data/code-cov.md

Co-authored-by: Nick Murphy <[email protected]>

Fix: edits from @namurphy to run tests page

Co-authored-by: Nick Murphy <[email protected]>

Update ci-tests-data/run-tests.md

Co-authored-by: Nick Murphy <[email protected]>

Author: lwasser

ci-tests-data/ci.md

@@ -8,17 +8,17 @@ These workflows include:
 - Building your documentation
 - Deploying your documentation to GitHub pages
 
-CI also allows you to automate running workflows across a suite of environments including:
+CI allows you to automate running workflows across a suite of environments including:
 
 - environments containing different Python versions and
-- different operating systems (Mac, Linux, Unix).
+- different operating systems (Mac, Linux, Windows).
 
 ### 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.
+- 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.
 
@@ -54,9 +54,9 @@ 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.
+- [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/) Had been 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

ci-tests-data/code-cov.md

@@ -8,6 +8,6 @@ A common service for analyzing code coverage is [codecov.io](https://codecov.io/
 :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
+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.
 
 ```

ci-tests-data/run-tests.md

@@ -135,14 +135,14 @@ tests = ["pytest", "pytest-cov"]
 
 If you have the above setup, then you can use `session.install(".[tests]")` to install your test dependencies.
 Notice that below one single nox session allows you to run
-your tests on 3 different Python environments (Python 3.9, 3.10 and 3.11).
+your tests on 3 different Python environments (Python 3.9, 3.10, 3.11, and 3.12).
 
 ```python
 import nox
 
 # For this to run you will need to have python3.9, python3.10 and python3.11 installed on your computer. Otherwise nox will skip running tests for whatever versions are missing
 
-@nox.session(python=["3.9", "3.10", "3.11"])
+@nox.session(python=["3.9", "3.10", "3.11", "3.12"])
 def test(session):
 
 # install
@@ -185,10 +185,10 @@ import nox
 
 # The syntax below allows you to use mamba / conda as your environment manager, if you use this approach you don’t have to worry about installing different versions of Python
 
-@nox.session(venv_backend='mamba', python=["3.9", "3.10", "3.11"])
+@nox.session(venv_backend='mamba', python=["3.9", "3.10", "3.11", "3.12"])
 def test_mamba(session):
     """Nox function that installs dev requirements and runs
-    tests on Python 3.9 through 3.11
+    tests on Python 3.9 through 3.12
     """
 
     # Install dev requirements