Looking for a project maintainer about ddt HOT 12 CLOSED

First of all, thank you for creating ddt. I use it regularly at work and in my personal projects so it's a shame to hear that you will no longer maintain it, but of course I understand the decision. One of the things I appreciate about ddt is that I can use whichever test runner I like and the tests can remain standard library compatible.

I'll have a look at the code, but I doubt that I would be able maintain it myself.

Thanks again.

from ddt.

Hi, I wanted to let you know that I could take on your project. I'm looking for a project to maintain in my spare time and ddt was of much use to me lately. I have 3+ years of professional development in python and even longer as a hobby developer.

from ddt.

Hey, I'm not 100% keen on taking over the project, but am interested to know exactly how you were able to replace ddt with py.test. If all ddt's functionality is available in maintained libraries, I think the best way to go would just be to add documentation about this to the readme.

I'm happy to help you in any way you might need, just let me know.

from ddt.

Jazzband maintains a number of community-supported Python repos. Consider transferring ownership there.

from ddt.

@interrogator, pytests' parameterization functionality replaced ddt for me. See https://docs.pytest.org/en/latest/parametrize.html.

from ddt.

@clintonb is pytest's parameterization compatible with the standard library test runner? ie. Can I @mark parametrize a unittest.TestCase subclass class method and have it work with when I run unittest?

from ddt.

No clue, but the point of pytest is to replace unittest. pytest supports running unittest-style tests. I recommend trying it for yourself to see how it works.

from ddt.

For pytest, django-dbdiff may help.

from ddt.

Seems to be resolved for now.

from ddt.

@clintonb is pytest's parameterization compatible with the standard library test runner? ie. Can I @mark parametrize a unittest.TestCase subclass class method and have it work with when I run unittest?

mark.parametrize is not supporting classes that inherit from unittest.TestCase
... and probably never will be (link), so IMO ddt library has still reason to be maintained.

from ddt.

@DamianSkrzypczak I'd argue that's more motivation to move to py.test-style tests (at least for those tests which need parameterization) and ditch unittest. That said, it's a moot point since @wswld seems to be maintaining the project.

Note that I no longer use Python on a daily basis (new job uses Ruby), so don't take any of this as gospel. I'm just an Internet guy who finds py.test better than unittest.

from ddt.

Hi! Thanks for response 😄

[You can skip this part, it's just personal point of view]
Don't get me wrong, both solutions (unittest/pytest) have some pros and cons for me,
for example:
cons:

• pytest is getting very big and "universal" and well... I think believe that "a jack of all trades is master of none"
• unittest in opposition is very very limited and simple.

pros:

• pytest is very intuitive and powerful, it's extensions system is pure gold
• unittest has very very nice assertions system, it may be better (expected/observed value) but it's still good, assert statement is something that I really dislike in python and I think it should be "functioned" as it was done with "print"... unit testing using it is... IMO just wrong.

[This is true message 😄]
I hope for future that pytest will be included in standard library, but as long as unittest is included there... it's more official and recommended solution, just because of this little fact. ^.^ It just makes it a little more trustworthy and then... reasonable for maintenance.

from ddt.