You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Return the sum of the numbers in the array, returning 0 for an empty array. Except the number 13 is very unlucky, so it does not count and numbers that come immediately after a 13 also do not count.
10
+
11
+
12
+
The tests that are used on codingbat:
13
+
14
+
sum13([1, 2, 2, 1]) → 6
15
+
sum13([1, 1]) → 2
16
+
sum13([1, 2, 2, 1, 13]) → 6
17
+
sum13([1, 2, 2, 1]) → 6
18
+
sum13([1, 1]) → 2
19
+
sum13([1, 2, 2, 1, 13]) → 6
20
+
sum13([1, 2, 13, 2, 1, 13]) → 4
21
+
sum13([13, 1, 2, 13, 2, 1, 13]) → 3
22
+
sum13([]) → 0
23
+
sum13([13]) → 0
24
+
sum13([13, 13]) → 0
25
+
sum13([13, 0, 13]) → 0
26
+
sum13([13, 1, 13]) → 0
27
+
sum13([5, 7, 2]) → 14
28
+
sum13([5, 13, 2]) → 5
29
+
sum13([0]) → 0
30
+
sum13([13, 0]) → 0
31
+
"""
32
+
33
+
importpytest
34
+
35
+
fromsum_13importsum13
36
+
37
+
38
+
# Using the nifty pytest.parametrize, so we only have to write one test
39
+
40
+
test_data= [
41
+
([1, 2, 2, 1], 6),
42
+
([1, 1], 2),
43
+
([1, 2, 2, 1, 13], 6),
44
+
([1, 2, 2, 1], 6),
45
+
([1, 1], 2),
46
+
([1, 2, 2, 1, 13], 6),
47
+
([1, 2, 13, 2, 1, 13], 4),
48
+
([13, 1, 2, 13, 2, 1, 13], 3),
49
+
([], 0),
50
+
([13], 0),
51
+
([13, 13], 0),
52
+
([13, 0, 13], 0),
53
+
([13, 1, 13], 0),
54
+
([5, 7, 2], 14),
55
+
([5, 13, 2], 5),
56
+
([0], 0),
57
+
([13, 0], 0),
58
+
# These are not part of original test suite
59
+
# uncomment them, and see if your solution still passes.
60
+
# ([3, 13, 13, 2, 5], 8),
61
+
# (iter([13, 1, 2, 13, 2, 1, 13]), 3), # Does it work with an iterable?
Copy file name to clipboardExpand all lines: _sources/index.rst.txt
+7-4Lines changed: 7 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -7,11 +7,14 @@
7
7
Programming in Python
8
8
#####################
9
9
10
-
This site holds many of the materials for the
10
+
This site holds a set of materials for an introductory course in Python.
11
+
12
+
THe course was originally developed by a wide variety of instructors for the
11
13
`University of Washington Professional and Continuing Education Python Certificate <https://www.pce.uw.edu/certificates/python-programming>`_
12
14
`Introductory class <https://www.pce.uw.edu/courses/programming-in-python>`_
13
15
14
-
This site can be thought of as the textbook for Programming in Python: the first course in the program. It contains notes about the topics covered in the classes, programming exercises, supplemental materials about setting up a development environment, and assorted references about Python-related topics.
16
+
This site can be thought of as the textbook for an introduction to programming in Python:
17
+
It contains notes about the topics covered in the classes, programming exercises, supplemental materials about setting up a development environment, and assorted references about Python-related topics.
15
18
16
19
Many of these topics can be useful on their own, but each assumes that you know concepts that were introduced earlier in the program, so working through them in order can be helpful.
17
20
@@ -35,7 +38,7 @@ They are built with the Sphinx documentation system, utilizing Restructured Text
Readers are encouraged to report omissions, typos, or make suggestions for improvements via issues and pull requests on that repository.
41
44
@@ -45,7 +48,7 @@ Example Code
45
48
46
49
Assorted Example code can be found in the source repository for these documents. Most of the examples are linked to directly from these documents, but it might be helpful to have them all in one place:
Copy file name to clipboardExpand all lines: _sources/modules/TestDrivenDevelopment.rst.txt
+6-10Lines changed: 6 additions & 10 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,8 +1,6 @@
1
1
2
2
.. _test_driven_development:
3
3
4
-
FIXME: change the path from my personal to something generic
5
-
6
4
#######################
7
5
Test Driven Development
8
6
#######################
@@ -16,7 +14,7 @@ Test Driven Development
16
14
"Test Driven Development" (TDD) is a development strategy that integrates the development of unit tests with the code itself. In particular, you write the tests *before* you write the code, which seems pretty backward, but it has some real strengths.
17
15
18
16
We'll demonstrate this technique with an example.
19
-
17
+
20
18
The following is adapted from Mark Pilgrim's excellent "Dive into Python":
21
19
22
20
https://diveintopython3.problemsolving.io/
@@ -105,7 +103,7 @@ want it to. You read that right: you’re going to write code that tests
105
103
code that you haven’t written yet.
106
104
107
105
This is called *test-driven development*, or TDD. The set of two
108
-
conversion functions — ``to_roman()``, and later ``from_roman()`` — can
106
+
conversion functions — ``to_roman()``, and later ``from_roman()`` — can
109
107
be written and tested as a unit, separate from any larger program that
110
108
uses them.
111
109
@@ -115,9 +113,7 @@ Technically, you can write unit tests with plain Python -- recall the ``assert``
115
113
116
114
$ python -m pip install pytest
117
115
118
-
Once installed, you should have the pytest command available in your terminal.
119
-
120
-
FIXME: Maybe add a small page on installing and using pytest?
116
+
Once installed, you should have the pytest command available in your terminal.
121
117
122
118
Unit testing is an important part of an overall testing-centric
123
119
development strategy. If you write unit tests, it is important to write
@@ -262,7 +258,7 @@ You don’t need to test every possible input, but you should try to test all th
262
258
263
259
.. note:: This is a major challenge of unit testing -- how to catch all the edge cases, without over testing every little thing.
264
260
265
-
`pytest` makes it really simple to write a test case: simply define a function named ``test_anything``. pytest will identify any function with: "``test_``"" at the start of the name as a test function.
261
+
`pytest` makes it really simple to write a test case: simply define a function named ``test_anything``. pytest will identify any function with: "``test_``" at the start of the name as a test function.
266
262
267
263
* Every individual test is its own function. A test function takes no parameters, returns no value, and must have a name beginning with the five letters ``test_``.
268
264
If a test function exits normally without a failing assertion or other exception, the test is considered passed; if the function raises a failed assertion, failed.
@@ -604,7 +600,7 @@ sort of failure; they must fail in the way you expect.
604
600
In [13]: to_roman(9000)
605
601
Out[13]: 'MMMMMMMMM'
606
602
607
-
That’s definitely *not* what you wanted — that’s not even a valid Roman
603
+
That’s definitely *not* what you wanted — that’s not even a valid Roman
608
604
numeral!
609
605
In fact, after 3000, each of these numbers is outside the range of
610
606
acceptable input, but the function returns a bogus value anyway.
@@ -684,7 +680,7 @@ code to pass it yet. Did it fail in the way you expected?
684
680
Yes! ``pytest.raises`` did its job -- a ``ValueError`` was not raised, and the test failed.
685
681
686
682
Of course, the ``to_roman()`` function isn’t raising the ``ValueError`` because you haven’t told it to do that yet.
687
-
That’s excellent news! It means this is a valid test case — it fails before you write the code to make it pass.
683
+
That’s excellent news! It means this is a valid test case — it fails before you write the code to make it pass.
688
684
689
685
Now you can write the code to make this test pass.
@@ -9,16 +9,47 @@ This page is a quick overview of testing in Python. It provides some background
9
9
10
10
Testing your code is an absolute necessity -- you need to have *some* way to know it's doing what it should.
11
11
12
+
Everyone tests their code -- that's how you know it works.
13
+
14
+
But when folks talk about "testing" -- what they really mean are automated tests.
15
+
12
16
Having your testing done in an automated way is really a good idea.
13
17
14
-
You've already seen a very basic testing strategy: putting some ``assert`` statements in the ``__name__ == "__main__"`` block.
15
18
16
-
You've written some tests using that strategy.
19
+
What is testing?
20
+
================
21
+
22
+
Code which runs your application in as close to a real environment as feasible and validates its behavior
23
+
24
+
25
+
Terminology of testing
26
+
----------------------
27
+
28
+
- Unit tests
29
+
- Integration tests
30
+
- High level system tests
31
+
- Acceptance tests
32
+
- Black box / White box testing
33
+
34
+
35
+
"V" model and tests levels
36
+
--------------------------
37
+
.. image:: /_static/test_v_model.png
38
+
39
+
Note that "codeing" is at the bottom, and directly tied to unit-testing -- that's the place to start.
40
+
41
+
About Unit Testing
42
+
------------------
17
43
18
-
These tests were pretty basic, and a bit awkward in places (testing error
19
-
conditions in particular).
44
+
0. Tests can be fully automated.
45
+
1. Tests should be independent.
46
+
2. Tests do not run in order, which shouldn't matter, see point 1.
47
+
3. Test fixtures are available to do any setup / teardown needed for tests.
48
+
4. Test behavior should not be implementation dependent.
49
+
5. Mocking is available to fake stuff you may not want to run in your tests.
50
+
51
+
This all applies regardless of your test framework
20
52
21
-
.. centered:: **It gets better**
22
53
23
54
Test Frameworks
24
55
---------------
@@ -49,108 +80,9 @@ It is a bit verbose: you have to write classes & methods (And we haven't covered
49
80
But you will see it used in others' code, so it's good to be familiar with it.
50
81
And seeing how verbose it can be will help you appreciate other options.
51
82
52
-
So here's a bit of an introduction -- if the class stuff confuses you, don't worry about it -- you don't need to actually DO this yourself at this point.
53
-
54
-
55
-
Using ``unittest``
56
-
------------------
57
-
58
-
To use ``unittest``, you need to write subclasses of the ``unittest.TestCase`` class (after importing the package, of course):
59
-
60
-
.. code-block:: python
61
-
62
-
# in test.py
63
-
import unittest
64
-
65
-
classMyTests(unittest.TestCase):
66
-
67
-
deftest_tautology(self):
68
-
self.assertEqual(1, 1)
69
-
70
-
Then you run the tests by using the ``main`` function from the ``unittest``
71
-
module:
72
-
73
-
.. code-block:: python
74
-
75
-
# in test.py
76
-
if__name__=='__main__':
77
-
unittest.main()
78
-
79
-
``unittest.main()`` is called in the module where the tests are. Which means that they can be, but do not have to be, in the same file as your code.
80
-
81
-
NOTE: tests can also be run by "test runners" for more features.
82
-
83
-
84
-
Testing Your Code
85
-
-----------------
86
-
87
-
You can write your code in one file and test it from another -- and for all but the smallest projects, you want to do that.
88
-
89
-
in ``my_mod.py``:
90
-
91
-
.. code-block:: python
92
-
93
-
defmy_func(val1, val2):
94
-
return val1 * val2
95
-
96
-
in ``test_my_mod.py``:
97
-
98
-
.. code-block:: python
99
-
100
-
import unittest
101
-
from my_mod import my_func
102
-
103
-
104
-
classMyFuncTestCase(unittest.TestCase):
105
-
deftest_my_func(self):
106
-
test_val1, test_val2 =2, 3
107
-
expected =6
108
-
actual = my_func(test_val1, test_val2)
109
-
self.assertEqual(expected, actual)
110
-
111
-
if__name__=='__main__':
112
-
unittest.main()
113
-
114
-
So this is pretty straightforward, but it's kind of a lot of code for just one test, yes?
115
-
116
-
117
-
Advantages of ``unittest``
118
-
--------------------------
119
-
120
-
The ``unittest`` module is pretty full featured
121
-
122
-
It comes with the standard Python distribution, no installation required.
123
-
124
-
It provides a wide variety of assertions for testing many types of results.
125
-
126
-
It allows for a "set up" and "tear down" work flow both before and after all tests and before and after each test.
127
-
128
-
It's well known and well understood.
129
-
130
-
131
-
Disadvantages of ``unittest``
132
-
-----------------------------
133
-
134
-
It's Object Oriented, and quite "heavyweight".
135
-
136
-
- modeled after Java's ``JUnit``.
137
-
138
-
It uses the Framework design pattern, so knowing how to use the features means learning what to override.
139
-
140
-
Needing to override means you have to be cautious.
141
-
142
-
Test discovery is both inflexible and brittle.
143
-
144
-
It doesn't really take advantage of Python's introspection capabilities:
145
-
- There are explicit "assert" methods for each type of test
146
-
- The available assertions are not the least bit complete
147
-
- All the assertions really do is provide pretty printing of errors
148
-
149
-
Testing for Exceptions is awkward
150
-
151
-
Test discovery is limited
83
+
See :ref:`advanced_testing` for more on that.
152
84
153
-
And there is no built-in parameterized testing.
85
+
For now -- we'regoingto us pytest -- far simpler to get started, and advanced enough for the largest, most complex projects.
0 commit comments