Skip to content

fix typo #5

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
confluence merged 1 commit into from
Nov 2, 2023
+3 −2
Merged

fix typo #5

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions CONTRIBUTORS
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,2 +1,3 @@
Adrianna Pińska <adrianna.pinska@gmail.com>
Simon Cross <hodgestar@gmail.com>
Joseph Sarpong <joseph-sarpong@hotmail.com>
2 changes: 1 addition & 1 deletion python_notes/Packaging_and_Testing.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -185,7 +185,7 @@ Selecting test cases

How do we select test cases? There are two major approaches that we can follow: *black-box* or *glass-box* testing. We can also use a combination of the two.

In black-box testing, we treat our function like an opaque "black box". We don't use our knowledge of how the function is written to pick test cases -- we only think about what the function is supposed to do. A strategy commonly used in black-box testing is is *equivalence testing* and *boundary value analysis*.
In black-box testing, we treat our function like an opaque "black box". We don't use our knowledge of how the function is written to pick test cases -- we only think about what the function is supposed to do. A strategy commonly used in black-box testing is *equivalence testing* and *boundary value analysis*.

An *equivalence class* is a set of input values which should all produce similar output, and there are *boundaries* between neighbouring equivalence classes. Input values which lie near these boundaries are the most likely to produce incorrect output, because it's easy for a programmer to use ``<`` instead of ``<=`` or start counting from ``1`` instead of ``0``, both of which could cause an *off-by-one* error. If we test an input value from inside each equivalence class, and additionally test values just before, just after and on each boundary, we can be reasonably sure that we have covered all the bases.

Expand Down
2 changes: 1 addition & 1 deletion python_notes/Sorting_and_Searching_Algorithms.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -261,7 +261,7 @@ Python. "..." denotes missing code that should be filled in::

def selection_sort(items):
"""Sorts a list of items into ascending order using the
selection sort algoright.
selection sort algorithm.
"""
for step in range(len(items)):
# Find the location of the smallest element in
Expand Down