FYI, pytest already does this: http://doc.pytest.org/en/latest/
Advertising
-- Ryan [ERROR]: Your autotools build scripts are 200 lines longer than your program. Something’s wrong. http://kirbyfan64.github.io/ On Sep 17, 2016 7:55 PM, "Arek Bulski" <arek.bul...@gmail.com> wrote: > I am using declarative testing a lot and I found out why unit tests are so > clunky. The reason why assertEquals(a,b) is used is because if we put > `assert a==b` then nose can catch the AssertionError but wont find out what > was returned or expected. This could be easily overcome if we allow > oveloading == operator from outside. Right now == would have to be changed > for every lefhand object that is compared in the tests, builtin types > including. We could use a way to change it from above, so to speak. > Consider this: > > def __glob_eq__(a,b): > if not a == b: > raise FoundInequalityError(a,b) > return True > > assert obj1 == obj2 #<-- using eq above > > Nose could easily catch FoundInequalityError and print whatever > assertEquals would. This goes very handy when you consider declarative unit > testing that I use in my project. I have a unitest.TestCase derivative and > the actual testcase has a method that yields individual comparisons, like > this: > > class TestBinary(declarativeunittest.TestCase): > def alltestsinteractive(self): > > yield [func(1) == 2] > shuffle(alist) > yield [sorted(alist) == [1,2,3]] > > Notice that this allows to put imperative statements in between > declarative cases. So shuffled() is no longer necessary in this code. :) > > pozdrawiam, > Arkadiusz Bulski > > > _______________________________________________ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
