Nooo, tylko że to nie wygląda jak dobry test, będzie Ci utrudniał refaktorowanie tego kodu w przyszłości.
Zamiast próbować uczyć się pisać testy po to żeby był, lepiej by było gdybyś znalazł jakiś tutorial, który nie skupia się na technicznych aspektach (jak np assert
), tylko na tym jak pisać dobre testy, tak żeby nie zapędzić się test-hell.
Jeśli faktycznie masz zadanie które brzmi, Write a Python program that accepts the user's first and last name and prints them in reverse order with a space between them
to jego implementacja faktycznie mogłaby wyglądać tak:
def get_name(Name, Sumrname):
data_list = [Name, Sumrname]
data_list.reverse()
data = data_list[0] + ' ' + data_list[1]
print(data)
name = input('Give your name > ')
surname = input('Give your surname > ')
get_name(name, surname)
Ale test nie powinien wyglądać tak jak to zostało zaproponowane, powinno to wyglądać jakoś tak:
application_input = "Jan\nKowalski"
application_output = execute(application_input)
assert application_output == "Kowalski Jan"
Przy czym execute()
to byłaby funkcja która wsadza wejście na standard input, i sprawdza standard output. W ten sposób napiszesz testy, który faktycznie testuje to co robi program (czyli input()
i print()
).
Jeśli nie chcesz tego robić, to możesz napisać test tylko pod get_name()
, ale wtedy powinieneś zabrać z niej print()
i nie mockować go w ogóle. Czyli musisz się zdecydować: zjeść ciastko lub mieć ciastko. Czyli albo piszesz test który bierze print()
oraz input()
na poważnie, i testuje je jak się powinno testować (czyli stubując stdin oraz stdout), albo nie testujesz ich w ogóle i wołasz samą get_name()
. Dodawanie takich cudów jak @patch('builtins.print')
jest dosłownie najgorszym wyjściem, które przyniesie Ci tylko nieszczęście.
Jeśli napiszesz test który robi mock_print.assert_called_with("Kowalski Jan")
, to nie będziesz mógł potem zrefaktorować print()
na np dwa printy, albo w zasadzie na nic innego bez zmiany testu - a to znaczy że test stanie się rigid, nie odporny na zmiany - nie rób tego.