Skip to content

Commit b93e579

Browse files
authored
Merge pull request #33 from UCL-ARC/32-add-refactoring-lesson
Add refactoring lesson
2 parents 5c73310 + f39b73f commit b93e579

5 files changed

Lines changed: 1363 additions & 171 deletions

File tree

README.md

Lines changed: 13 additions & 77 deletions
Original file line numberDiff line numberDiff line change
@@ -1,84 +1,20 @@
1-
# The Carpentries Workbench Template Markdown Lesson
1+
# Fortran unit testing lesson
22

3-
This lesson is a template lesson that uses [The Carpentries Workbench][workbench].
3+
A lesson for teaching how to unit test Fortran code.
44

5-
## Note about lesson life cycle stage
6-
Although the `config.yaml` states the life cycle stage as pre-alpha, **the template is stable and ready to use**. The life cycle stage is preset to `"pre-alpha"` as this setting is appropriate for new lessons initialised using the template.
5+
## Building the website locally
76

8-
## Create a new repository from this template
7+
From within RStudio run the following commands. First, install the needed dependencies.
98

10-
To use this template to start a new lesson repository,
11-
make sure you're logged into Github.
12-
Visit https://github.com/carpentries/workbench-template-md/generate
13-
and follow the instructions.
14-
Checking the 'Include all branches' option will save some time waiting for the first website build
15-
when your new repository is initialised.
9+
```r
10+
install.packages(c("sandpaper", "varnish", "pegboard")) # This may not need to be called as frequently as the following commands
11+
```
1612

17-
If you have any questions, contact [@tobyhodges](https://github.com/tobyhodges)
13+
Then can build the site
1814

19-
## Configure a new lesson
15+
```r
16+
setwd('/path/to/fortran-unit-testing-lesson')
17+
sandpaper::build_lesson()
18+
```
2019

21-
Follow the steps below to
22-
complete the initial configuration of a new lesson repository built from this template:
23-
24-
1. **Make sure GitHub Pages is activated:**
25-
navigate to _Settings_,
26-
select _Pages_ from the left sidebar,
27-
and make sure that `gh-pages` is selected as the branch to build from.
28-
If no `gh-pages` branch is available, check the _Actions_ tab to see if the first
29-
website build workflows are still running.
30-
If they're not running yet, you may need to manually enable them via the _Actions_ tab.
31-
The branch should become available when those have completed.
32-
1. **Adjust the `config.yaml` file:**
33-
this file contains global parameters for your lesson site.
34-
Individual fields within the file are documented with comments (beginning with `#`)
35-
At minimum, you should adjust all the fields marked 'FIXME':
36-
- `title`
37-
- `created`
38-
- `keywords`
39-
- `life_cycle` (the default, _pre-alpha_, is the appropriate for brand new lessons)
40-
- `contact`
41-
1. **Annotate the repository** with site URL and topic tags:
42-
navigate back to the repository landing page and
43-
click on the gear wheel/cog icon (similar to ⚙️)
44-
at the top-right of the _About_ box.
45-
Check the "Use your GitHub Pages website" option,
46-
and [add some keywords and other annotations to describe your lesson](https://cdh.carpentries.org/the-carpentries-incubator.html#topic-tags)
47-
in the _Topics_ field.
48-
At minimum, these should include:
49-
- `lesson`
50-
- the life cycle of the lesson (e.g. `pre-alpha`)
51-
- the human language the lesson is written in (e.g. `deutsch`)
52-
1. **Adjust the
53-
`CITATION.cff`, `CODE_OF_CONDUCT.md`, `CONTRIBUTING.md`, and `LICENSE.md` files**
54-
as appropriate for your project.
55-
- `CITATION.cff`:
56-
this file contains information that people can use to cite your lesson,
57-
for example if they publish their own work based on it.
58-
You should [update the CFF][cff-sandpaper-docs] now to include information about your lesson,
59-
and remember to return to it periodically, keeping it updated as your
60-
author list grows and other details become available or need to change.
61-
The [Citation File Format home page][cff-home] gives more information about the format,
62-
and the [`cffinit` webtool][cffinit] can be used to create new and update existing CFF files.
63-
- `CODE_OF_CONDUCT.md`:
64-
if you are using this template for a project outside The Carpentries,
65-
you should adjust this file to describe
66-
who should be contacted with Code of Conduct reports,
67-
and how those reports will be handled.
68-
- `CONTRIBUTING.md`:
69-
depending on the current state and maturity of your project,
70-
the contents of the template Contributing Guide may not be appropriate.
71-
You should adjust the file to help guide contributors on how best
72-
to get involved and make an impact on your lesson.
73-
- `LICENSE.md`:
74-
in line with the terms of the CC-BY license,
75-
you should ensure that the copyright information
76-
provided in the license file is accurate for your project.
77-
1. **Update this README with
78-
[relevant information about your lesson](https://carpentries.github.io/lesson-development-training/collaborating-newcomers.html#readme)**
79-
and delete this section.
80-
81-
[cff-home]: https://citation-file-format.github.io/
82-
[cff-sandpaper-docs]: https://carpentries.github.io/sandpaper-docs/editing.html#making-your-lesson-citable
83-
[cffinit]: https://citation-file-format.github.io/cff-initializer-javascript/
84-
[workbench]: https://carpentries.github.io/sandpaper-docs/
20+
This will create a local build of the site at [site/docs/index.html](./site/docs/index.html).

config.yaml

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -34,7 +34,7 @@ life_cycle: 'pre-alpha'
3434
license: 'CC-BY 4.0'
3535

3636
# Link to the source repository for this lesson
37-
source: 'https://github.com/UCL-ARC/fortran-unit-testing-lesson/'
37+
source: 'https://github.com/UCL-ARC/fortran-unit-testing-lesson'
3838

3939
# Default branch of your lesson
4040
branch: 'main'
@@ -66,8 +66,8 @@ contact: 'c.aird@ucl.ac.uk'
6666

6767
# Order of episodes in your lesson
6868
episodes:
69-
- 1-intro-to-unit-tests.md
70-
- 2-intro-to-fortran-unit-tests.md
69+
- 1-what-is-a-unit-tests.md
70+
- 2-refactor-fortran.md
7171
- 3-fortran-unit-test-syntax.md
7272
- 4-debugging-a-broken-test.md
7373
- 5-testing-parallel-code.md

episodes/1-what-is-a-unit-tests.md

Lines changed: 6 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -20,7 +20,6 @@ exercises:
2020

2121
::::::::::::::::::::::::::::::::::::::::::::::::
2222

23-
## What is unit testing?
2423

2524
Unit testing is a way of verifying the validity of a code base by testing its smallest individual components, or **units**.
2625

@@ -35,14 +34,14 @@ Several key aspects define a unit test. They should be...
3534

3635
::::::::::::::::::::::::::::::::::::: callout
3736

38-
#### Other forms of testing
37+
### Other forms of testing
3938

4039
There are other forms of testing, such as integration testing in which two or more units of a code base are tested to verify that they work together, or that they are correctly **integrated**.
4140
However, today we are focusing on unit tests as it is often the case that many of these larger tests are written using the same test tools and frameworks, hence we will make progress with both by starting with unit testing.
4241

4342
::::::::::::::::::::::::::::::::::::::::::::::::
4443

45-
### What does a unit test look like?
44+
## What does a unit test look like?
4645

4746
All unit tests tend to follow the same pattern of Given-When-Then.
4847

@@ -58,7 +57,7 @@ All unit tests tend to follow the same pattern of Given-When-Then.
5857

5958
::::::::::::::::::::::::::::::::::::: challenge
6059

61-
#### Challenge 1: Write a unit test in sudo code.
60+
### Challenge 1: Write a unit test in sudo code.
6261

6362
Assuming you have a function `reverse_array` which reverses the order of an allocated array. Write a unit test in pseudo code for `reverse_array` using the pattern above.
6463

@@ -82,7 +81,7 @@ for each element in `input_array`:
8281
:::::::::::::::::::::::::::::::::
8382
::::::::::::::::::::::::::::::::::::::::::
8483

85-
### When should unit tests be run?
84+
## When should unit tests be run?
8685

8786
A major benefit of unit tests is the ability to identify bugs at the earliest possible stage. Therefore, unit tests should be run frequently throughout the development process. Passing unit tests give you and your collaborators confidence that changes to your code aren't modifying the previously expected behaviour, so run your unit tests...
8887

@@ -95,7 +94,7 @@ A major benefit of unit tests is the ability to identify bugs at the earliest po
9594

9695
Basically, all the time.
9796

98-
### Do we really need unit tests?
97+
## Do we really need unit tests?
9998

10099
Yes!
101100

@@ -117,7 +116,7 @@ This is much clearer. We immediately have an idea of what could be going wrong a
117116

118117
::::::::::::::::::::::::::::::::::::: challenge
119118

120-
### Challenge 2: Unit test bad practices
119+
## Challenge 2: Unit test bad practices
121120

122121
Take a look at [1-into-to-unit-tests/challenge](https://github.com/UCL-ARC/fortran-unit-testing-exercises/tree/main/episodes/1-into-to-unit-tests/challenge) in the exercises repository.
123122

episodes/2-intro-to-fortran-unit-tests.md

Lines changed: 0 additions & 84 deletions
This file was deleted.

0 commit comments

Comments
 (0)