Miroirs/cooperative-software-development
1
0
Fork 0
mirror of https://github.com/amyjko/cooperative-software-development synced 2024-12-25 21:58:15 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions

Removed extra backtick.

Browse source
This commit is contained in:
Amy J. Ko 2021-07-18 16:48:58 -07:00
parent f5eeaac3e7
commit e27c9d8ffc
1 changed files with 2 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
chapters/specifications.md
View file

@ -11,7 +11,7 @@ In their simplest form, a functional specification can be a just some natural la
// or if they're equal, the second number.
function min(a, b) {
return a < b ? a : b;
}
}
`
This comment achieves the core purpose of a specification: to help other developers understand what the requirements and intended behavior of a function are. As long as everyone sticks to this "plan" (everyone calls the function with only numbers and the function always returns the smaller of them), then there shouldn't be any problems.
@ -33,7 +33,7 @@ Of course, if the above was JavaScript code (which doesn't support static typing
This brings us to a second purpose of writing functional specifications: to help _verify_ that functions, their input, and their output are correct. Tests of functions and other low-level procedures are called *unit tests*. There are many ways to use specifications to verify correctness. By far, one of the simplest and most widely used kinds of unit tests are *assertions*<clarke06>. Assertions consist of two things: 1) a check on some property of a function's input or output and 2) some action to notify about violations of these properties. For example, if we wanted to verify that the JavaScript function above had integer values as inputs, we would do this:
``javascript
`javascript
// Return the smaller of the two numbers, or if they're equal, the second number.
function min(a, b) {
if(!Number.isInteger(a))