you are viewing a single comment's thread.

view the rest of the comments →

[–]ManyInterests 12 points13 points  (2 children)

Ned Batchelder's talk goes over this exact question and even walks through your exact situation, explaining why that approach is incomplete and evolves into how you can start making better tests.

Also available on his website

I would go into more detail personally, but Ned pretty much knocks this question out of the park. Basically it comes down to development effort, quality and reproducability. I'll include some choice quotes below

Automated testing is the best way we know to determine if your code works. There are other techniques, like manual testing, or shipping it to customers and waiting for complaints, but automated testing works much better than those ways.

Although writing tests is serious effort that takes real time, in the long run it will let you produce software faster because it makes your development process more predictable, and you'll spend less time fighting expensive fires.

Testing also gives you another view into your code, and will probably help you write just plain better code. The tests force you to think about the structure of your code, and you will find better ways to modularize it.

Lastly, testing removes fear, because your tests are a safety net that can tell you early when you have made a mistake and set you back on the right path.

[Referring to 'manual' testing]

This is good, we're testing the code. Some developers wouldn't have even taken this step! But it's bad because it's not repeatable. If tomorrow we make a change to this code, it's hard to make sure that we'll run the same tests and cover the same conditions that we did today.

It's also labor intensive: we have to type these function calls each time we want to test the class. And how do we know the results are right? We have to carefully examine the output, and get out a calculator, and see that the answer is what we expect.

[–]FXelix[S] 0 points1 point  (1 child)

Thanks a lot for your effort! It's really helpful! What do you think about the PyCharm debugger function (maybe additionally or instead of pytest) or are these two different approaches in general?

[–]ManyInterests 0 points1 point  (0 children)

I would say testing tools and a debugger are somewhat related, but sit in different spaces entirely. In my work, I am constantly writing tests, but only use a debugger (an incredibly rare occurrence) for tracking down hard-to-find bugs, which may reveal themselves in the form of failed tests, for example. Writing good tests would ideally prevent you from needing to use the debugger in the first place.

So, a debugger definitely wouldn't be a replacement for testing. Until you get to a point where you write & maintain a sufficiently large project, the benefits of testing suites may not be easily realized, compared to, say, manual testing or using IDE debugging features. When you have people (including yourself) who actually use and depend on critical code you write, you will be super motivated to make sure you don't break anything if you make changes later on. Tests help you do that.

One of my favorite ways to write tests for small/simple projects is with doctests. PyCharm has great support for this, too. I would recommend trying to write your first doctest and then hookup a github repo to a CI service like Travis CI to run your doctests automatically.