utest conversion tool question
I am still dizzy and sick, but I am trying to get something done anyhow. I have this question. If you start with self.assertEquals(f(x) + g(x) == q(x), 'Message to print when the assertion fails') you would like things to come back as assert f(x) +\ g(x) == q(x), 'Message to print when the assertion fails' It is the last, optional message which is the sticky part, otherwise you could say, just keep the original parentheses. But this does not work, as the following demonstrates:
The problem is that once you get into 'backslash pasting' mode, it is hard to know when you should stop. I was working on the assumption that if we have something that works like an expression, but doesn't work when you peal off the parens, i.e. it is multi-line, then you should paste the parens in. And this is mostly correct. But there is this problem.
thus if I get some code: self.assertNotEquals(''' aaa bbb ccc ''', s) I should not be pasting in the backslashes. But
.... suggestions on how to recognise triple-quoted strings? Apologies if I miss something obvious, my brain isn't really good for much yet. Laura
Hello Laura, On Wed, Jun 30, 2004 at 04:43:25PM +0200, Laura Creighton wrote:
There is probably always a way to avoid backslashes. For the above example it would be: assert (f(x) + g(x) == q(x)), 'Message' Inserting these parenthesis shouldn't be too hard if you decompose the arguments anyway. Also note that the same rule applies to each of the two arguments of the assert statement: self.assertEquals(f(x) + g(x) == q(x), 'Message') should, intuitively, get translated to... assert (f(x) + g(x) == q(x)), ( 'Message') I guess once you know the text of each argument to assert, you can check which ones contain a '\n' and add parenthesis in this case. In the above example if the second argument starts right after the original ',' then it should be "\n 'Message'" i.e. including a '\n', so it gets parenthesis too. Armin
Hi Armin, [Armin Rigo Wed, Jun 30, 2004 at 07:35:14PM +0100]
Aehem, which kind of intuition are you invoking? I guess intuitive as seen from an algorithm but certainly not nice for a human eye, right? (apart from the fact, that the first '==' probably should be a comma). So i would suggest assert f(x) + g(x) == q(x), 'Message' as the desired output unless this is NP-complete to compute :-) cheers, holger
Hello Holger, On Wed, Jun 30, 2004 at 09:05:05PM +0200, holger krekel wrote:
Well, I was assuming that f(x), g(x) and q(x) were actually much longer. Otherwise the original statement wouldn't have been split either. For example: self.assertEquals(if_we_do_something("with a long string") + "and concatenate that", then_we_get(2*3), 'Message') assert (if_we_do_something("with a long string") + "and concatenate that" == then_we_get(2*3)), ( 'Message') In general I think we should not try to rearrange the lines too hard; 'assert' is a bit shorter than 'self.assertEquals(' but then not dramatically so. The translation could be beautified by reindenting it entierely, but this looks like a dangerous thing to do in the current model and isn't absolutely necessary. Armin
Is there any publicly accessible document on utest? the basic design, what it is about, how it differs from unitest? Is replacing .assertEquals with assert the main thing? Are you catching AssertionError in order to continue with further tests or are you using a customized test-mode assert? Looking at the PyPy site, I only found 'New unit testing framework (not ready yet)' on the Test Design page, a paragraph in the Amsterdam report, and the current utest threads that began June 15 and which assume pre-existing knowledge of what utest is. I am asking because I want to use TDD on a new project, from the beginning, but I am not especially happy with either doctest or unittest. (The latter could work, but the heavy class framework reminds me of why I use Python instead of Java ;-). Terry J. Reedy
Hi Terry, [Terry Reedy Thu, Jul 01, 2004 at 01:42:42PM -0400]
Is there any publicly accessible document on utest? the basic design, what it is about, how it differs from unitest?
unfortunately currently not, there only is http://codespeak.net/svn/user/hpk/talks/std-talk.txt
We are building AssertionErrors so that they contain detailed information about the asertion-expressions. For this, we override the builtin-AssertionError but re-interpreting arbitrary exceptions from the catching-side of std.utest is also possible.
Yes, this is a ll more or less outdated, sorry.
Then you should definitely consider std.utest. I hope to have more instructions ready soon. i am just incredibly busy with other stuff (among them the dreaded EU PyPy negotiations). cheers, Holger
"holger krekel" <hpk@trillke.net> wrote in message news:20040701175119.GU16751@solar.trillke... This
and this
are enough that I can understand this http://codespeak.net/svn/std/trunk/src/std/ , /magic, /utest well enough to get ideas for what I need. =============================================== "Thomas Heller" <theller@python.net> wrote in message news:fz8br3t1.fsf@python.net...
Funny you should quote this. In the process of writing my query, it dawned on me that this is one wheel I maybe should reimplement. The core of what I actually need to get started is something like for func in implementations: for case in functable: try: result = func(case[0]) assert result == case[1] except AssertionError: print "Whoops,', result, ' is not', case[1] print ============================================== Thank you both for the quick and helpful push. This utest discussion has gotten me to see beyond trying to choose between doctest and unittest. Terry J. Reedy
"Terry Reedy" <tjreedy@udel.edu> writes: [...]
Reminds me of what Kent Beck writes (test-driven development by example, Addison-Wesley, page 119): """ xUnit has been ported to more than 30 programming languages as of this writing. Your language is likely to have an implementation already. But there are a couple of reasons for implementing xUnit yourself, even if there is a version already available: * Mastery - The spirit of xUnit is simplicity. Martin Fowler said, "Never in the annals of software engineering was so much owed by so many to so few lines of code." Some of the implementations have gotten a little complicated for my taste. Rolling your own will give you a tool over which you have a feeling of mastery. [...] """ Thomas
Hey Laura, [Laura Creighton Wed, Jun 30, 2004 at 04:43:25PM +0200]
I am still dizzy and sick, but I am trying to get something done anyhow. I have this question.
ups, didn't know you were ill, but you seem to have fun recovering :-)
Oh, ^^^^ you mean a comma here, i guess?!
actually i'd prefer assert f(x) + g(x) == q(x), 'Message to print when the assertion fails' Because i think the output logic should just format it so that it looks nice (e.g. less < 76 characters per line) and retain the correct semantics of the original statement. I wouldn't worry about the original input format, though. If this proves too hard then maybe blame Armin who suggested the 'comma'-try-parsing-withought-understanding-the expression-tricks :-) Regarding your string-parsing question ...
I think you are mixing the string s with its repr-esentation in source code. When you actually try-to-parse self.assertNotEquals(''' aaa bbb ccc ''', s) then you will at some point pass "'\naaa\nbbb\nccc'" to parser.expr() which will succeed. HTH and happy recovery, Holger
Hello Laura, On Wed, Jun 30, 2004 at 04:43:25PM +0200, Laura Creighton wrote:
There is probably always a way to avoid backslashes. For the above example it would be: assert (f(x) + g(x) == q(x)), 'Message' Inserting these parenthesis shouldn't be too hard if you decompose the arguments anyway. Also note that the same rule applies to each of the two arguments of the assert statement: self.assertEquals(f(x) + g(x) == q(x), 'Message') should, intuitively, get translated to... assert (f(x) + g(x) == q(x)), ( 'Message') I guess once you know the text of each argument to assert, you can check which ones contain a '\n' and add parenthesis in this case. In the above example if the second argument starts right after the original ',' then it should be "\n 'Message'" i.e. including a '\n', so it gets parenthesis too. Armin
Hi Armin, [Armin Rigo Wed, Jun 30, 2004 at 07:35:14PM +0100]
Aehem, which kind of intuition are you invoking? I guess intuitive as seen from an algorithm but certainly not nice for a human eye, right? (apart from the fact, that the first '==' probably should be a comma). So i would suggest assert f(x) + g(x) == q(x), 'Message' as the desired output unless this is NP-complete to compute :-) cheers, holger
Hello Holger, On Wed, Jun 30, 2004 at 09:05:05PM +0200, holger krekel wrote:
Well, I was assuming that f(x), g(x) and q(x) were actually much longer. Otherwise the original statement wouldn't have been split either. For example: self.assertEquals(if_we_do_something("with a long string") + "and concatenate that", then_we_get(2*3), 'Message') assert (if_we_do_something("with a long string") + "and concatenate that" == then_we_get(2*3)), ( 'Message') In general I think we should not try to rearrange the lines too hard; 'assert' is a bit shorter than 'self.assertEquals(' but then not dramatically so. The translation could be beautified by reindenting it entierely, but this looks like a dangerous thing to do in the current model and isn't absolutely necessary. Armin
Is there any publicly accessible document on utest? the basic design, what it is about, how it differs from unitest? Is replacing .assertEquals with assert the main thing? Are you catching AssertionError in order to continue with further tests or are you using a customized test-mode assert? Looking at the PyPy site, I only found 'New unit testing framework (not ready yet)' on the Test Design page, a paragraph in the Amsterdam report, and the current utest threads that began June 15 and which assume pre-existing knowledge of what utest is. I am asking because I want to use TDD on a new project, from the beginning, but I am not especially happy with either doctest or unittest. (The latter could work, but the heavy class framework reminds me of why I use Python instead of Java ;-). Terry J. Reedy
Hi Terry, [Terry Reedy Thu, Jul 01, 2004 at 01:42:42PM -0400]
Is there any publicly accessible document on utest? the basic design, what it is about, how it differs from unitest?
unfortunately currently not, there only is http://codespeak.net/svn/user/hpk/talks/std-talk.txt
We are building AssertionErrors so that they contain detailed information about the asertion-expressions. For this, we override the builtin-AssertionError but re-interpreting arbitrary exceptions from the catching-side of std.utest is also possible.
Yes, this is a ll more or less outdated, sorry.
Then you should definitely consider std.utest. I hope to have more instructions ready soon. i am just incredibly busy with other stuff (among them the dreaded EU PyPy negotiations). cheers, Holger
"holger krekel" <hpk@trillke.net> wrote in message news:20040701175119.GU16751@solar.trillke... This
and this
are enough that I can understand this http://codespeak.net/svn/std/trunk/src/std/ , /magic, /utest well enough to get ideas for what I need. =============================================== "Thomas Heller" <theller@python.net> wrote in message news:fz8br3t1.fsf@python.net...
Funny you should quote this. In the process of writing my query, it dawned on me that this is one wheel I maybe should reimplement. The core of what I actually need to get started is something like for func in implementations: for case in functable: try: result = func(case[0]) assert result == case[1] except AssertionError: print "Whoops,', result, ' is not', case[1] print ============================================== Thank you both for the quick and helpful push. This utest discussion has gotten me to see beyond trying to choose between doctest and unittest. Terry J. Reedy
"Terry Reedy" <tjreedy@udel.edu> writes: [...]
Reminds me of what Kent Beck writes (test-driven development by example, Addison-Wesley, page 119): """ xUnit has been ported to more than 30 programming languages as of this writing. Your language is likely to have an implementation already. But there are a couple of reasons for implementing xUnit yourself, even if there is a version already available: * Mastery - The spirit of xUnit is simplicity. Martin Fowler said, "Never in the annals of software engineering was so much owed by so many to so few lines of code." Some of the implementations have gotten a little complicated for my taste. Rolling your own will give you a tool over which you have a feeling of mastery. [...] """ Thomas
Hey Laura, [Laura Creighton Wed, Jun 30, 2004 at 04:43:25PM +0200]
I am still dizzy and sick, but I am trying to get something done anyhow. I have this question.
ups, didn't know you were ill, but you seem to have fun recovering :-)
Oh, ^^^^ you mean a comma here, i guess?!
actually i'd prefer assert f(x) + g(x) == q(x), 'Message to print when the assertion fails' Because i think the output logic should just format it so that it looks nice (e.g. less < 76 characters per line) and retain the correct semantics of the original statement. I wouldn't worry about the original input format, though. If this proves too hard then maybe blame Armin who suggested the 'comma'-try-parsing-withought-understanding-the expression-tricks :-) Regarding your string-parsing question ...
I think you are mixing the string s with its repr-esentation in source code. When you actually try-to-parse self.assertNotEquals(''' aaa bbb ccc ''', s) then you will at some point pass "'\naaa\nbbb\nccc'" to parser.expr() which will succeed. HTH and happy recovery, Holger
participants (5)
-
Armin Rigo -
holger krekel -
Laura Creighton -
Terry Reedy -
Thomas Heller