Live data from Hacker News

Pynguin – Generate Python unit tests automatically

github.com

51–60 of 80 posts

Re: Pynguin – Generate Python unit tests automatically

#51

Earlier quoted context omitted.

Let's say you test an api, since yoy are taling about status code. You have to test all kind of cases with wrong inputs, various user states and so on. You can of course write the test to simulate all that, but's way harder than just using your user UI which lets you discover it and put a breakpoint in the endpoint to inspect. I may not remember where to get the header data in this framework, or maybe the client send…

your whole argument is a straw-man. i don't think that anyone would disagree that you can get caught up in writing too many tests too early, consequently loosing sight out of your objective and ending up with a bad implementation. My point was that just writing super easy and happy-path tests at the start is a valid strategy for TDD as well, and does not cause any of your imaginary issues.

Aggressive tone and a throw away account, this is the end of the thread for me.

Re: Pynguin – Generate Python unit tests automatically

#52
post #4

Sometimes automated testing is the only way to go. Consider a case when you have a code that takes about 100 input parameters and makes a decision on whether something should or should not happen. The logic that determines the decision is about 1,000 LOC that doesn't divide easily into smaller chunks. The code consists of a lot of different conditions and calculations based on the input parameters and some constants.…

Years ago, in a similar situation, I wrote a tool to capture parameters and results for the algorithm while QA ran their full application test suite. Ended up with a few thousand cases and expected results; results where QA had verified the software worked as expected.

Used that to create a test suite that we could then maintain normally.

Much better than random.

Re: Pynguin – Generate Python unit tests automatically

#54
post #53

Can anyone recommend a good online course on software testing (preferably using python)?

Harry Percival, famous by "Obey the Goat" also his new book "Cosmic Python" this guy is a genius at teaching :) both books available at the respective sites

https://www.obeythetestinggoat.com/pages/book.html#toc

http://www.cosmicpython.com/

If you feel that TDD is too much there is a book about pytest, tho never really focused on it.

Hope it helps,

PS: Ty Harry :)

Re: Pynguin – Generate Python unit tests automatically

#55
post #42
post #34

If I write faulty code, the generated test will make sure I keep the code faulty right?

Yup, and their example shows it: https://pynguin.readthedocs.io/en/latest/user/quickstart.htm... The example is a function which reports the kind of triangle. The generated tests include one that tests that a triangle with sides 12, 12 and... er... None is "isosceles".

That kinda sucks, since the function is type hinted...

Re: Pynguin – Generate Python unit tests automatically

#56
post #46
post #41

Pynguin executes the module under test! As a consequence, depending on what code is in that module, running Pynguin can cause serious harm to your computer, for example, wipe your entire hard disk! We recommend running Pynguin in an isolated environment, for example, a Docker container, to minimise the risk of damaging your system.

This warning quoted from the README doesn't seem to suggest anything unexpected or unusual. Obviously running the tests would execute the module under test. (Although I suppose if someone wanted to generate tests without ever executing them the warning would be relevant.)

This warning is very important. It’s absolutely not expected that generating tests means executing module code, side effects and all.

Re: Pynguin – Generate Python unit tests automatically

#57
post #15

Just in case you are looking for an alternative approach: if you write contracts in your code, you might also consider crosshair [1] or icontract-hypothesis [2]. If your function/method does not need any pre-conditions then the the type annotations can be directly used. (I'm one of the authors of icontract-hypothesis.) [1] https://github.com/pschanely/CrossHair [2] https://github.com/mristin/icontract-hypothesis

Coding with contracts has always been interesting to me but I haven't had the option/time to try it seriously in a project. I assume you've had experience with it, how much productivity/code maintanability you gain compared to not using it (or using type annotations)?

In my anecdotal experience, it takes very little time for juniors to pick up adding contracts to their code. You need to grasp implication, equivalence, exclusive or, and get used to declarative code, but then it's easy. (I often compare it to SQL.)

I find contracts personally super useful as I can express a lot of relationships in the code trivially and have them automatically verified. For example, when this input is None, then that output needs to be positive. Or if you dele the item it should not exist in this and that registry, and some related other items should also not exist any more.

My email is in the commits of the repository, feel free to contact me and we can have a chat if you are interested in a larger picture and more details.

Re: Pynguin – Generate Python unit tests automatically

#58
The best use case I see for this is when you inherit a testless codebase. It's a way to get bootstrapped, and go from there.

Sometimes you have to honor bugs as part of the (undocumented/evolved/inferred) interface. It could help to discover these, walk through them and see where they can be fixed or where they need to be honored.

It could also help prevent the "rewrite from scratch because I don't understand it" problem. Heck, I've even done that to myself picking up a codebase I haven't touched in 3+ years, sometimes validly, sometimes notsomuch.

I'll have to see how it works next time this happens to me, because this is pure conjecture.

Re: Pynguin – Generate Python unit tests automatically

#59

I can see this being useful for refactoring legacy codebases. You create assertions for existing code, whether correct or wrong as a result of existing bugs, and then make sure nothing changes after your refactor. For new code, not so much. The generated tests wouldn't prevent bugs by themselves, but they may uncover bugs if you see assertions that don't make sense. But you have to spend time reviewing the tests. The…

> Sometimes the code behavior might be intentionally ambiguous, not expected to matter in the real world and behavior that will likely change in the future that you should not depend on today.

That is a bad thing and should be addressed. It’s code like this that will inevitably cause you pain later and very likely become significant code debt.

Re: Pynguin – Generate Python unit tests automatically

#60

Earlier quoted context omitted.

your whole argument is a straw-man. i don't think that anyone would disagree that you can get caught up in writing too many tests too early, consequently loosing sight out of your objective and ending up with a bad implementation. My point was that just writing super easy and happy-path tests at the start is a valid strategy for TDD as well, and does not cause any of your imaginary issues.

Aggressive tone and a throw away account, this is the end of the thread for me.

Rereading my comment does indeed sound very aggressive. It wasn't intentional and I'm sorry for that. I have to work on that.
Post reply on HN