Jarekz: /* Sprawdzanie pokrycia kodu przez testy */

2015-05-23T10:34:19Z

Sprawdzanie pokrycia kodu przez testy

Jarekz: /* Testowanie (na przykładzie klasy Wektor) */

2015-05-23T10:32:19Z

Testowanie (na przykładzie klasy Wektor)

Jarekz: Utworzono nową stronę " ==Boxcar== ===Model urządzenia pomiarowego===
Modelujemy urządzenie typu ''boxcar'': układ pomiarowy dostarcza..."

2015-05-23T10:30:03Z

Utworzono nową stronę " ==Boxcar== ===Model urządzenia pomiarowego=== thumb|350px|<figure id="uid1" /> Modelujemy urządzenie typu ''boxcar'': układ pomiarowy dostarcza..."

Nowa strona

==Boxcar==
===Model urządzenia pomiarowego===

[[Plik:boxcar.jpg|thumb|350px|<figure id="uid1" />]]

Modelujemy urządzenie typu ''boxcar'': układ pomiarowy dostarcza
próbki (liczby zmienno-przecinkowe) sekwencyjnie, a ''boxcar''
w każdym momencie przechowuje ostatnie <math>N</math> z nich i na żądanie zwraca
średnią i odchylenie standardowe.

Jeśli pomiar dopiero się zaczął i próbek jest mniej niż <math>N</math>, obliczenia
są wykonywane na mniejszej liczbie próbek.

Nasz kod napiszemy w postaci klasy.

====Etap 1: Przechowywanie danych====

Poszczególne próbki będziemy przechowywać w strukturze danych, która pozwala na
dodanie nowego elementu na początek sekwencji i usunięcie starego elementu z końca sekwencji.

W Pythonie jest już struktura, która zapewnia takie możliwości — zwykła lista (<tt>[]</tt>, klasa <tt>list</tt>).

Zapamiętanie nowej próbki realizujemy jej na początek sekwencji próbek. Po dodaniu nowego elementu
sprawdzamy, czy nie mamy zbyt dużo próbek. Jeśli jest ich więcej niż <math>N</math>, to usuwamy najstarszy.

<source lang=python>
class Boxcar(object):
def __init__(self, N):
self.dane = []
self.N = N

def nowy_pomiar(self, pomiar):
self.dane.insert(0, pomiar)
if len(self.dane) > self.N:
self.dane.pop()
</source>

Konstruując naszą klasę w ten sposób zrealizowaliśmy jeden z postulatów programowania obiektowego:
nasze dane nie są bezpośrednio widoczne dla użytkowników naszej klasy <tt>Boxcar</tt>. Również
za to w jaki sposób dane są przechowywane, za inicjalizację odpowiednich struktur odpowiada wyłącznie
klasa <tt>Boxcar</tt>. Użytkownik klasy jedynie tworzy obiekt <tt>Boxcar</tt> i wywołuje
na nim metodę <code>nowy_pomiar</code>. To właśnie enkapsulacja i rozdzielenie obowiązków.

====Etap 2: Obliczenia====
Do implementacji klasy Boxcar dodajmy metodę <tt>srednia</tt>.

<source lang="python">
def srednia(self):
suma = sum(self.dane)
liczba = len(self.dane)
return suma/liczba
</source>

====Zadanie 1====
Dodaj do klasy metodę <tt>dyspersja</tt>, która zwróci odchylenie <math>\sigma</math> pamiętanych próbek od średniej.

Przypomnienie:
:<math>\sigma = \sqrt{\sum_1^N \frac{\left(x-\bar x\right)^2}{N(N-1)</math>
:gdzie średnia
:<math>\bar x = \sum_1^N \frac{x}{N}</math>

====Zadanie 2====
Zaprojektuj tekstową reprezentację obiektu.
Dodaj do klasy metodę <tt>__str__</tt>, która wypisze tekstową reprezentację obiektu klasy.

====Zadanie 3====
Sprawdź swoją implementację boxcara, wypełniając go liczbami losowymi z rozkładu płaskiego.

===Etap 3: Wykorzystanie enkapsulacji===

Lista nie jest idealną strukturą danych do przechowania pomiarów ponieważ operacja wstawienia
lub usunięcia elementu na początek listy jest operacją niewydajną.

Poszczególne próbki powinniśmy przechowywać w strukturze danych, która pozwala na szybkie
dodanie nowego elementu na początek sekwencji i usunięcie starego elementu z końca sekwencji.

W standardowej bibliotece Pythona jest już dostępna właśnie taka struktura: <tt>collections.deque</tt>.

Przykład użycia klasy <code>deque</code>:

<source lang = python>
>>> import collections
>>> q = collections.deque()
>>> q.appendleft(1)
>>> q.appendleft(2)
>>> q.appendleft(3)
>>> q
deque([3, 2, 1])
</source>

Zmodyfikujmy implementację klasy <tt>Boxcar</tt> tak, by wykorzystać <tt>deque</tt> zamiast <tt>list</tt>.
Interfejs klasy ani jej zachowanie nie mają prawa się zmienić!

<source lang=python>
class Boxcar(object):
def __init__(self, N):
self.dane = collections.deque()
self.N = N

def nowy_pomiar(self, pomiar):
self.dane.appendleft(pomiar)
if len(self.dane) > self.N:
self.dane.pop()

# reszta klasy pozostaje bez zmian!
</source>

Istnieją dwa podstawowe sposoby wykorzystania kodu jednej klasy przy tworzeniu drugiej — dziedziczenie i kompozycja.
W tym wypadku do konstrukcji klasy <tt>boxcar</tt> wykorzystaliśmy klasę <tt>list</tt> a potem <tt>deque</tt>. Zrobiliśmy to poprzez kompozycję: dane są przechowywane w zmiennej <tt>self.dane</tt>, natomiast klasa <tt>boxcar</tt> wywołuje metody na tym obiekcie w miarę potrzeby. Alternatywą byłoby zastosowanie dziedziczenia — klasa <tt>boxcar</tt> dziedziczyłaby po <tt>list</tt> czy <tt>deque</tt>. Te dwa rozwiązania możemy podsumować tak:
albo <tt>boxcar</tt> '''ma''' kolejkę danych, albo <tt>boxcar</tt> '''jest''' kolejką danych.
Dziedziczenie ma tę wadę, że nasza nowa klasa ma zupełnie niepotrzebne metody, np. <tt>reverse</tt>, odziedzione po klasie macierzystej. O ile funkcjonalność jest podobna przy jednym i drugim rozwiązaniu, to kompozycja jest tutaj rozwiązaniem znacznie bardziej eleganckim.
Jest to zgodne z ogólną zasadą dobrego programowania obiektowego, że '''kompozycja jest lepsza niż dziedziczenie'''.
===Etap 4:tworzenie obiektu typu Boxcar, korzystając z iterowalnego kontenera z danymi===
Dokumentacja do obiektu <tt>collections.deque</tt> pokazuje, że tego typu obiekty można inicjalizować, korzystając z obiektów, które są iterowalne (np. listy). Zmiana konstruktora klasy Boxcar tak, żeby można było wykorzystać tę własność <tt>deque</tt> byłaby bardzo wygodna, bo umożliwiałaby tworzenie obiektów typu Boxcar w oparciu o istniejące już kontenery z danymi.

====Zadanie 4====
Zmień konstruktor klasy Boxcar, tak by umożliwiał opcjonalne tworzenie obiektu w oparciu o istniejący już kontener z danymi. Uwzględnij sytuację, w której kontener ten zawiera więcej pomiarów niż założona długość bufora. Postaraj się zmienić kontruktor tak, by był jak najbardziej odporny na próby podania nieodpowiednich danych.

==Testowanie (na przykładzie klasy Wektor)==

Mamy klasę <tt>Wektor</tt>. Jak wygodnie sprawdzić czy działa poprawnie? Odpowiedź: [http://codespeak.net/py/dist/test/ py.test].

Ponieważ nasz moduł definiujący <tt>Wektor</tt> jest króciusieńki, funkcje testujące możemy dodać do tego samego modułu. W przypadku dużych programów tworzy się nawet osobny podkatalog (często <tt>tests/</tt>), tutaj nie warto.
Dopisuję więc fukcje sprawdzające mnożenie:

<source lang = pycon>
# ...
# definicja klasy Wektor
# ...
def test_mul():
w1 = Wektor(1, 2)
w2 = Wektor(3, 4)
assert w1 * w2 == 11

def test_mul_with_zeros():
w1 = Wektor(0, 2)
w2 = Wektor(3, 0)
assert w1 * w2 == 0
</source>

Aby sprawdzić nasz kod, używamy polecenia <tt>py.test</tt>:
{{color|teal|$ '''py.test wektor.py -v’’’}}
============================= test session starts =============================
python: platform linux2 -- Python 2.6.4 -- pytest-1.1.1 -- /usr/bin/python
test object 1: .../wektor/wektor.py

wektor.py:60: test_mul {{color|green|PASS}}
wektor.py:65: test_mul_zeros {{color|green|PASS}}

========================== 2 passed in 0.01 seconds ===========================
Działa!

Teraz dodajmy funkcję testującą dodawanie:
<source lang = python>
# ...
# definicja klasy Wektor
# ...
# testy mnożenia
# ...
def test_add():
w1 = Wektor(1, 2)
w2 = Wektor(3, 4)
assert w1 + w2 == Wektor(4, 6)
</source>

Ponownie odpalmy <tt>py.test</tt>:
{{color|teal|$ '''py.test wektor.py -v’’’}}
============================= test session starts =============================
python: platform linux2 -- Python 2.6.4 -- pytest-1.1.1 -- /usr/bin/python
test object 1: .../wektor/wektor.py

wektor.py:60: test_mul {{color|green|PASS}}
wektor.py:65: test_mul_zeros {{color|green|PASS}}
wektor.py:70: test_add {{color|red|FAIL}}

================================== FAILURES ===================================
__________________________________ test_add ___________________________________

def test_add():
w1 = Wektor(1, 2)
w2 = Wektor(3, 4)
> assert w1 + w2 == Wektor(4, 6)
{{color|red|E assert (<Wektor(1, 2) @140050567247696> + <Wektor(3, 4) @140050567248016>) <nowiki>==</nowiki> <Wektor(4, 6) @140050567291216>}}
{{color|red|E + where <Wektor(4, 6) @140050567291216> <nowiki>=</nowiki> Wektor(4, 6)

wektor.py:73: AssertionError}}
===================== 1 failed, 2 passed in 0.06 seconds ======================
Nie działa! Dlaczego?

Oczywiście w wyrażeniu <tt>w1 + w2 == Wektor(4, 6)</tt> wykorzystujemy nie tylko operator <tt>+</tt>,
ale również operator <tt>==</tt>, który [http://docs.python.org/reference/datamodel.html#object.__eq__ wywołuje]
metodę <tt>__eq__</tt> obiektu z lewej strony. Ponieważ klasa <tt>Wektor</tt> nie zawiera definicji <tt>__eq__</tt>,
to zostaje wywołana domyślna wersja tej metody. Domyślna wersja nie wie nic o współrzędnych wektora
i po prostu wykonuje porównanie tożsamości obiektów (z grubsza <tt>is</tt>).

Aby test <tt>test_add</tt> przeszedł, mamy dwie możliwości. Możemy zmienić funkcję testującą tak, żeby
po prostu samemu sprawdzała równość współrzędnych:
<source lang = python>
# ...
# definicja klasy Wektor
# ...
# testy mnożenia
# ...
def test_add():
w1 = Wektor(1, 2)
w2 = Wektor(3, 4)
wynik = w1 + w2
assert wynik.a == 4 and wynik.b == 6
</source>
Niestety nie jest to rozwiązanie zbyt eleganckie, w szczególności musimy wiedzieć ile jest współrzędnych oraz jak się nazywają.

Drugą opcją jest dodanie implementacji porównywania wektorów do klasy <tt>Wektor</tt>.
Oczywiście ma to sens tylko wtedy, gdy uważamy, że chcemy mieć porównywanie obiektów niezależnie od testów.
Nie należy dodawać funkcjonalności do klasy tylko po to by ułatwić pisanie testów.
<source lang = python>
# ...
# definicja klasy Wektor
# ...
def __eq__(self, other):
return self.a == other.a and self.b == other.b
#
# testy mnożenia
#
def test_add():
w1 = Wektor(1, 2)
w2 = Wektor(3, 4)
assert w1 + w2 == Wektor(4, 6)
</source>

Ponowne uruchomienie <tt>py.test</tt> skutkuje poprawnym wykonaniem trzech testów.

=== Wykonywalne przykłady w dokumentacji ===
''Docstringi'' w <tt>Wektor</tt> są nieco zbyt zwięzłe. Bardzo wygodne dla użytkownika są proste
wykonywalne przykłady, które można przekleić do interpretera i trochę poeksperymentować.
Zapisuje się je w ''docstringu''. Znaczki >>> poprzedzają fragmenty do wykonania, a wyniki
wypisywane przez Pythona się po prostu poprzedza spacjami.
Łatwo się domyślić, że tak jest dlatego, że można po prostu przekleić wykonywane przykłady
z interaktywnej sesji, nie trzeba niczego wymyślać.

Spróbujmy:
<source lang = python>
class Wektor(object):
"""Dwuwymiarowy wektor.

>>> print Wektor(3, 5)
(3, 5)

>>> print Wektor(3, 5) + Wektor(-1, -1)
(2, 4)
"""
# ...
# reszta definicji klasy
#
</source>
Teraz osoba pisząca <tt>help(Wektor)</tt> od razu zorientuje się jak można użyć tej klasy.
Polecenia <tt>print</tt> użyłem zamiast po prostu wykonania wyrażenia tworzącego nowy <tt>Wektor</tt>
po to, by uniknąć nieistotnych szczegółów, np. wypisywania adresu przez <tt>Wektor.__repr__</tt>.

=== Testowanie z wykorzystaniem docstringów ===
Jeśli ktoś postanawia skorzystać z wykonywalnych poleceń zapisanych w docstringach,
a nie działają one tak jak należy, zazwyczaj nie jest szczęśliwy. Dlatego
należy sprawdzać, czy zapisane przykłady zachowują się nadal tak, jak zachowywały się kiedy
osoba pisząca dokumentację wkleiła je do niej.

Służy do tego moduł <tt>doctest</tt>.
<source lang = pycon>
$ python -m doctest -v wektor.py
Trying:
print Wektor(3, 5)
Expecting:
(3, 5)
ok
Trying:
print Wektor(3, 5) + Wektor(-1, -1)
Expecting:
(2, 4)
ok
15 items had no tests:
# ...
# lista funkcji bez testów pominięta
# ...
1 items passed all tests:
2 tests in wektor.Wektor
2 tests in 16 items.
2 passed and 0 failed.
Test passed.
</source>

Również <tt>py.test</tt> pozwala na wykorzystanie wykonywalnych docstringów:
<source lang = pycon>
$ python -m doctest -v wektor.py
</source>
Takie wywołanie również skutkuje modułu <tt>doctest</tt> i daje identyczny efekt.

=== Sprawdzanie pokrycia kodu przez testy ===
Uważa się, że w dobrze przetestowanym projekcie, liczba linii kodu w fukcjach testujących to 100-200% linii kodu w głównej części.
Na pewno nie jest łatwo odpowiedzieć na pytanie, czy nasze testy faktycznie sprawdzają wszystko co należy. Niemniej często łatwo jest powiedzieć czego ''nie'' sprawdzają — jeśli jakaś funkcja czy fragement kodu w trakcie testów nie jest wogóle uruchamiany,
to znaczy, że z całą pewnością nie jest testowany.

Do sprawdzania pokrycia kodu przez testy w połączeniu z <tt>py.test</tt> służy wtyczka [http://darcs.idyll.org/~t/projects/figleaf/doc/ figleaf]:
{{color|teal|$ '''py.test wektor.py -v'''}}
============================= test session starts =============================
python: platform linux2 -- Python 2.6.4 -- pytest-1.1.1 -- /usr/bin/python
test object 1: .../wektor/wektor.py

wektor.py:60: test_mul {{color|green|PASS}}
wektor.py:65: test_mul_zeros {{color|green|PASS}}
wektor.py:70: test_add {{color|green|PASS}}
----------------------------------- figleaf -----------------------------------
Writing figleaf data to .../wektor/.figleaf
Writing figleaf html to file://.../wektor/html

========================== 3 passed in 0.08 seconds ===========================
Wtyczka <tt>figleaf</tt> powoduje wygenerowanie plików HTML zawierających kopię kodu
programu z liniami oznaczonymi kolorami.
: {{color|green|Zielony oznacza, że linia została wykonana w trakcie testów przynajmniej raz}}
: {{color|red|Czerwony oznacza, że linia nie była wogóle użyta}}
: {{color|black|Czarny oznacza, że linia nie zawiera wykonywalnego kodu, a np. komentarz czy ''docstring''.}}

source file: /home/zbyszek/python/wektor/wektor.py
file stats: 33 lines, 24 executed: 72.7% covered
1. # -*- coding: utf-8 -*-
{{color|green|2. class Wektor(object):
3. """Dwuwymiarowy wektor."""
4.
{{color|green|5. _ile_nas <nowiki>=</nowiki> 0
6.
{{color|green|7. def __init__(self, a, b):
8. self.a <nowiki>=</nowiki> a
9. self.b <nowiki>=</nowiki> b
10. Wektor._ile_nas <nowiki>+=</nowiki> 1
11.
{{color|green|12. def dlugosc(self):
13. """Zwraca liczbę, długość Wektora."""
{{color|red|14. return (self.a**2 + self.b**2)**0.5
# ...
# reszta pominięta
#

Dzięki takiej pomocy możemy łatwo zobaczyć które fragmenty programu wymagają napisania więcej testów.
W tym przykładzie widać, że metoda <tt>Wektor.dlugosc</tt> jest takim fragmentem.

====Zadanie 1====
Dopisać program testujący powyższą klasę.
====Zadanie 2====
Napisz klasę Kwadrat. Obiekty tej klasy powinny:
* przechowywać długość boku kwadratu
* posiadać reprezentację napisową
* posiadać metody zwracające pole i obwód kwadratu
* operator dodawania zdefiniowany tak, aby obiekt powstały w wyniku dodawania dwóch kwadratów miał pole równe sumie pól kwadratów składowych
Następnie napisz program testujący tęże klasę.

=== Dodatki ===
* [[/wektor.py|końcowa wersja kodu]]
* [http://escher.fuw.edu.pl/~zbyszek/wektor_figleaf pełen wynik działania figleaf] poza tym wiki

==Wczytywanie pliku raz jeszcze==
Czy pamiętasz [[TI/Zadanie_zabawa_z_sygnałem_rzeczywistym|zadanie, w którym należało wczytać pliki i narysować widmo z zadanego kanału]]?

====Zadanie 1====
Zaprojektuj własną klasę, która zapewni obsługę pliku binarnego, zawierającego multipleksowany sygnał o zadanej częstości próbkowania, liczbie kanałów, typie liczb. Zastanów się jakie jeszcze mogą być parametry takiego pliku. Zastanów się, jakie są jej niezbędne pola i napisz jej konstruktor i metodę <tt>__str__</tt>.

Zastanów się, jak najwygodniej będzie leniwemu użytkownikowi korzystać z obiektów zaprojektowanej i zaimplementowanej przez siebie klasy. Zastanów się, czy nie warto jest wczytywać pliku od razu w konstruktorze klasy (przekazywać nazwę pliku, częstość próbkowania i liczbę kanałów, jako argumenty konstruktora klasy.

Zastanów się, jak zaprojektować metodę <tt>__str__</tt>, żeby nie wypisywała całego sygnału na ekran, ale wyświetlała najważniejsze o nim informacje.

====Zadanie 2====
Do zaprojektowanej klasy dodaj następujące metody:
* zwracającą cały sygnał z wybranego kanału (możesz w konstruktorze dodać opisy kanałów, jeżeli dysponujesz opisem pliku i zawrzeć metodę, która zwraca sygnał z elektrody o odpowiedniej nazwie),
* zwracającą wybrany fragment sygnału z wybranej elektrody (np. sygnał od sekundy <math>t_1</math> do sekundy <math>t_2</math>),
* zwracającą wybrany fragment sygnału z wszystkich elektrod (np. od sekundy <math>t_1</math> do sekundy <math>t_2</math>),
* rysującą widmo wybranego fragmentu sygnału z wybranej elektrody,
* rysującą widmo fragmentu wszystkich sygnałów z wszystkich elektrod.
* zwracającą fragmenty sygnału o zadanej długości z wybranej elektrody, zaczynające się od kolejnych triggerów. Załóż, że w kanale z danym triggerem, wystąpienie triggera jest zaznaczone 1 (wartość 0, oznacza brak triggera),
* przygotuj się na możliwość występowania kanału specjalnego z triggerem (w takiej formie jak na Pracowni Sygnałów Bioelektrycznych). Dodaj metody uśredniające fragmenty sygnału o zadanej długości z wybranej elektrody, zaczynające się od kolejnych triggerów i rysujące ich widmo. Zastanów się jak najlepiej przekazywać informację o tym, że któryś kanał jest kanałem "specjalnym", np. triggerem. Do przetestowania cięcia danych wg triggera można użyć [http://escher.fuw.edu.pl/~mm/KAMIL/ stąd] (wybrane pliki .raw), lub danych samodzielnie zebranych na pracowni,
*stwórz klasę, dziedziczącą po powyższej, przedefiniowującą metody do wczytywania danych tak, aby obsługiwać duże pliki. To znaczy nie trzymającą całych danych w pamięci, lecz umiejącą wczytać wskazany fragment danych — wybrany kawałek, od sekundy ''t''<sub>1</sub>, do ''t''<sub>2</sub>, z kanałów podanych w liście kanalów. We wczytywaniu pliku nie korzystaj z metody <tt>fromfile</tt>. Otwórz plik metodą <tt>open</tt>, następnie wylicz do którego miejsca w pliku masz przejść używając metody <tt>seek</tt> obiektu typu plik (podaj o ile bajtów ma się przesunąć) i wczytaj kolejne próbki metodą <tt>read</tt>. Argumentem metody <tt>read</tt> jest liczba bajtów do wczytania, upewnij się więc, czy pamiętasz, że liczby typu double zajmują 8 bajtów. Tak wczytane próbki musisz jeszcze zamienić ze stringów na liczby typu double (pamiętając o porządku zapisu bajtów), korzystając np. z funkcji <tt>unpack</tt> modułu <tt>struct</tt>.

====Zadanie 3====
Spróbuj przeciążyć metodę <tt>__init__</tt>, tak żeby można było konstruować obiekty, korzystając z nazwy pliku (wczytując go w konstruktorze) albo z wektora z danymi.

Szkic prostszej metody:

<source lang="python">
def __init__(self, dane=None, plik=None):
if (dane is None) + (plik is None) != 1:
... #np. sys.exit(1)
</source>

Szkic bardziej skomplikowanej metody (wykorzystującej dekoratory):
<source lang="python">
class Dane(object):
def __init__(self, dane):
self.dane = dane
@classmethod
def fromfile(cls, name):
return cls(np.fromfile(dane))
</source>

====Zadanie 4====
Do klasy z dwóch pierwszych zadań dodaj przeciążony operator addycji (dodawania), który tworzyć będzie obiekt z sygnałem, składającym się z obu sygnałów. Pamiętaj o sprawdzeniu, że sygnały są tego samego typu — np. mają tyle samo kanałów i tę samą częstość próbkowania. Czy są jeszcze jakieś operatory, które warto w tej sytuacji przeładować?

====Zadanie 5====
Zaprojektuj klasę zapewniającą obsługę pliku z danymi kalibrującymi z [http://brain.fuw.edu.pl/~asia/BCICIV_calib_ds1a.mat IV BCI Competition]. Przypomnij sobie [http://bbci.de/competition/iv/desc_1.html opis tych danych]. Napisz konstruktor, w którym będziesz wczytywać plik i metodę <tt>__str__</tt>, która będzie zwracać najważniejsze informacje na temat danych zawartych w pliku.

====Zadanie 6====
Do zaprojektowanej przez siebie powyżej klasy, dodaj metody, które:
* zwrócą sygnał z wybranego kanału,
* zwroci listę wszystkich fragmentów sygnału odpowiadający danej klasie bodźca i danemu kanałowi,
* zwrócą uśredniony sygnał odpowiadający danej klasie bodźca i danemu kanałowi (uśredniamy "triale"),
* narysują i zapiszą do pliku widma z triali odpowiadających danej klasie bodźca i danemu kanałowi (w nazwie pliku ma się znaleźć informacja o tym dla którego triala, której klasy i którego kanału jest to widmo),
* narysują widmo po uśrednieniu widm ze wszystkich triali dla danej klasy bodźca.

@@ Linia 327: / Linia 327: @@
 . # -*- coding: utf-8 -*-
     {{color|green|2. class Wektor(object):
-.     """Dwuwymiarowy wektor."""
+.     """Dwuwymiarowy wektor."""}}
 .
-    {{color|green|5.     _ile_nas <nowiki>=</nowiki> 0
+    {{color|green|5.     _ile_nas <nowiki>=</nowiki> 0}}
 .
     {{color|green|7.     def __init__(self, a, b):
 .         self.a <nowiki>=</nowiki> a
 .         self.b <nowiki>=</nowiki> b
-.         Wektor._ile_nas <nowiki>+=</nowiki> 1
+.         Wektor._ile_nas <nowiki>+=</nowiki> 1}}
 .
-   {{color|green|12.     def dlugosc(self):
+   {{color|green|12.     def dlugosc(self):}}
 .         """Zwraca liczbę, długość Wektora."""
-   {{color|red|14.         return (self.a**2 + self.b**2)**0.5
+   {{color|red|14.         return (self.a**2 + self.b**2)**0.5}}
    # ...
    # reszta pominięta
@@ Linia 355: / Linia 355: @@
 * operator dodawania zdefiniowany tak, aby obiekt powstały w wyniku dodawania dwóch kwadratów miał pole równe sumie pól kwadratów składowych
 Następnie napisz program testujący tęże klasę.
 === Dodatki ===

@@ Linia 187: / Linia 187: @@
   >       assert w1 + w2 == Wektor(4, 6)
   {{color|red|E       assert (<Wektor(1, 2) @140050567247696> + <Wektor(3, 4) @140050567248016>) <nowiki>==</nowiki> <Wektor(4, 6) @140050567291216>}}
-  {{color|red|E        +  where <Wektor(4, 6) @140050567291216> <nowiki>=</nowiki> Wektor(4, 6)
+  {{color|red|E        +  where <Wektor(4, 6) @140050567291216> <nowiki>=</nowiki> Wektor(4, 6)}}
-  wektor.py:73: AssertionError}}
+  wektor.py:73: AssertionError
   ===================== 1 failed, 2 passed in 0.06 seconds ======================
 Nie działa! Dlaczego?
@@ Linia 360: / Linia 360: @@
 * [[/wektor.py|końcowa wersja kodu]]
 * [http://escher.fuw.edu.pl/~zbyszek/wektor_figleaf pełen wynik działania figleaf] poza tym wiki
 ==Wczytywanie pliku raz jeszcze==

TI/Wstęp do programowania obiektowego/Zadania - Historia wersji

Jarekz: /* Sprawdzanie pokrycia kodu przez testy */

Jarekz: /* Testowanie (na przykładzie klasy Wektor) */

Jarekz: Utworzono nową stronę " ==Boxcar== ===Model urządzenia pomiarowego=== Modelujemy urządzenie typu ''boxcar'': układ pomiarowy dostarcza..."

Jarekz: Utworzono nową stronę " ==Boxcar== ===Model urządzenia pomiarowego===
Modelujemy urządzenie typu ''boxcar'': układ pomiarowy dostarcza..."