On 27 Nov, 16:32, "Emanuele D'Arrigo" <[EMAIL PROTECTED]> wrote:
> On Nov 27, 5:00 am, Steven D'Aprano
>
> <[EMAIL PROTECTED]> wrote:
> > Refactor until your code is simple enough to unit-test effectively, then
> > unit-test effectively.
>
> Ok, I've taken this wise suggestion on board and of cours
Steven D'Aprano schreef:
[..]
Thank you for elaborate answer, Steven. I think I'm really starting to
get it now.
--
The saddest aspect of life right now is that science gathers knowledge
faster than society gathers wisdom.
-- Isaac Asimov
Roel Schroeven
--
http://mail.python.org/mailman/l
Steven D'Aprano wrote:
On Sun, 30 Nov 2008 03:42:50 +, Steven D'Aprano wrote:
def lcm(a, b):
return a/gcd(a, b)*b
(By the way: there's a subtle bug in lcm() that will hit you in Python
3. Can you spot it?
Er, ignore this. Division in Python 3 only returns a float if the
remainder i
On Sun, 30 Nov 2008 03:42:50 +, Steven D'Aprano wrote:
> def lcm(a, b):
> return a/gcd(a, b)*b
>
> (By the way: there's a subtle bug in lcm() that will hit you in Python
3. Can you spot it?
Er, ignore this. Division in Python 3 only returns a float if the
remainder is non-zero, and whe
On Sat, 29 Nov 2008 17:13:00 +0100, Roel Schroeven wrote:
> Except that I'm always told that the goal of unit tests, at least
> partly, is to protect us agains mistakes when we make changes to the
> tested functions. They should tell me wether I can still trust spam()
> after refactoring it. Doesn
Thanks for your answer. I still don't understand completely though. I
suppose it's me, but I've been trying to understand some of this for
quite some and somehow I can't seem to wrap my head around it.
Steven D'Aprano schreef:
On Sat, 29 Nov 2008 11:36:56 +0100, Roel Schroeven wrote:
The firs
On Nov 29, 3:33 am, "Emanuele D'Arrigo" <[EMAIL PROTECTED]> wrote:
> On Nov 29, 12:35 am, Fuzzyman <[EMAIL PROTECTED]> wrote:
>
> > Your experiences are one of the reasons that writing the tests *first*
> > can be so helpful. You think about the *behaviour* you want from your
> > units and you test
On Sat, 29 Nov 2008 11:36:56 +0100, Roel Schroeven wrote:
> Fuzzyman schreef:
>> By the way, to reduce the number of independent code paths you need to
>> test you can use mocking. You only need to test the logic inside the
>> methods you create (testing behaviour), and not every possible
>> combi
Fuzzyman schreef:
By the way, to reduce the number of independent code paths you need to
test you can use mocking. You only need to test the logic inside the
methods you create (testing behaviour), and not every possible
combination of paths.
I don't understand that. This is part of something I
On Nov 29, 12:35 am, Fuzzyman <[EMAIL PROTECTED]> wrote:
> Your experiences are one of the reasons that writing the tests *first*
> can be so helpful. You think about the *behaviour* you want from your
> units and you test for that behaviour - *then* you write the code
> until the tests pass.
Than
Thank you to everybody who has replied about the original problem. I
eventually refactored the whole (monster) method over various smaller
and simpler ones and I'm now testing each individually. Things have
gotten much more tractable. =)
Thank you for nudging me in the right direction! =)
Manu
--
On Nov 27, 4:32 pm, "Emanuele D'Arrigo" <[EMAIL PROTECTED]> wrote:
> On Nov 27, 5:00 am, Steven D'Aprano
>
> <[EMAIL PROTECTED]> wrote:
> > Refactor until your code is simple enough to unit-test effectively, then
> > unit-test effectively.
>
> Ok, I've taken this wise suggestion on board and of cou
[EMAIL PROTECTED] wrote:
Terry Reedy:
A 'function' only needs to be nested if it is intended to be
different (different default or closure) for each execution of its
def.<
Or maybe because you want to denote a logical nesting, or maybe
because you want to keep the outer namespace cleaner,
In article <[EMAIL PROTECTED]>,
Nigel Rantor <[EMAIL PROTECTED]> wrote:
> Roy Smith wrote:
> >
> > There's a well known theory in studies of the human brain which says people
> > are capable of processing about 7 +/- 2 pieces of information at once.
>
> It's not about processing multiple tak
Steven D'Aprano a écrit :
(snip)
Consequently, I almost always use single-underscore "private by
convention" names, rather than double-underscore names. The name-mangling
is, in my experience, just a nuisance.
s/just/most often than not/ and we'll agree on this !-)
--
http://mail.python.org/m
Roy Smith wrote:
There's a well known theory in studies of the human brain which says people
are capable of processing about 7 +/- 2 pieces of information at once.
It's not about processing multiple taks, it's about the amount of things
that can be held in working memory.
n
--
http://
On Fri, 28 Nov 2008 00:06:01 -0800, bearophileHUGS wrote:
>>For this to change wouldn't be a little change, it would be a large
>>change.<
>
> I see, then my proposal has little hope, I presume. I'll have to keep
> moving functions outside to test them and move them inside again when I
> want to
Terry Reedy:
>The problem is that inner functions do not exist until the outer function is
>called and the inner def is executed. And they cease to exist when the outer
>function returns unless returned or associated with a global name or
>collection.<
OK.
>A 'function' only needs to be nes
On Thu, 27 Nov 2008 08:32:12 -0800, Emanuele D'Arrigo wrote:
> On Nov 27, 5:00 am, Steven D'Aprano
> <[EMAIL PROTECTED]> wrote:
>> Refactor until your code is simple enough to unit-test effectively,
>> then unit-test effectively.
>
> Ok, I've taken this wise suggestion on board and of course I fo
On Thu, 27 Nov 2008 10:45:47 -0800, bearophileHUGS wrote:
> A question for other people: Can Python change a little to allow nested
> functions to be tested? I think this may solve some of my problems.
Remember that nested functions don't actually exist as functions until
the outer function is c
On Nov 27, 5:47 pm, Terry Reedy <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > Emanuele D'Arrigo:
> >> I can fragment the code of the original method into one public method and
> >> a few private support methods.<
>
> > Python also support nested functions, that you can put into your
>
[EMAIL PROTECTED] wrote:
Emanuele D'Arrigo:
I can fragment the code of the original method into one public method and a few
private support methods.<
Python also support nested functions, that you can put into your
method. The problem is that often unit test functions aren't able to
test nest
Emanuele D'Arrigo:
>I can fragment the code of the original method into one public method and a
>few private support methods.<
Python also support nested functions, that you can put into your
method. The problem is that often unit test functions aren't able to
test nested functions.
A question
Emanuele D'Arrigo wrote:
On Nov 27, 5:00 am, Steven D'Aprano
<[EMAIL PROTECTED]> wrote:
Refactor until your code is simple enough to unit-test effectively, then
unit-test effectively.
Ok, I've taken this wise suggestion on board and of course I found
immediately ways to improve the method. -Ho
On Nov 27, 5:00 am, Steven D'Aprano
<[EMAIL PROTECTED]> wrote:
> Refactor until your code is simple enough to unit-test effectively, then
> unit-test effectively.
Ok, I've taken this wise suggestion on board and of course I found
immediately ways to improve the method. -However- this generates
ano
In article <[EMAIL PROTECTED]>,
Stefan Behnel <[EMAIL PROTECTED]> wrote:
> Not to mention that you can sometimes look at awfully trivial code three
> times and only see the obvious bug in that code the fourth time you put an
> eye on it a good night's sleep later.
Or never see it.
Lately, I've
Steven D'Aprano wrote:
> If you don't test all the paths, then by definition you
> have program paths which have never been tested. Unless those paths are
> so trivially simple that you can see that they must be correct just by
> looking at the code, then the chances are very high that they will
On Nov 27, 5:00 am, Steven D'Aprano
<[EMAIL PROTECTED]> wrote:
> Refactor until your code is simple enough to unit-test effectively, then
> unit-test effectively.
I suspect you are right...
Ok, thank you!
Manu
--
http://mail.python.org/mailman/listinfo/python-list
On Wed, 26 Nov 2008 18:54:52 -0800, Emanuele D'Arrigo wrote:
> Hi everybody,
>
> another question on unit testing, admittedly not necessarily a python-
> specific one...
>
> I have a class method about 60 lines long (*) and due to some 9 non-
> trivial IFs statements (3 and 2 of which nested) th
Hi everybody,
another question on unit testing, admittedly not necessarily a python-
specific one...
I have a class method about 60 lines long (*) and due to some 9 non-
trivial IFs statements (3 and 2 of which nested) the number of
possible paths the program flow can take is uncomfortably large,
30 matches
Mail list logo
