keskiviikko 9. marraskuuta 2016 2.25.59 UTC Steve D'Aprano kirjoitti:
> On Wed, 9 Nov 2016 10:01 am, teppo...@gmail.com wrote:
>
> > Generally, with testing, it would be optimal to test outputs of the system
> > for given inputs without caring how things are implemented.
>
> I disagree with that
Steve D'Aprano :
> On Wed, 9 Nov 2016 10:01 am, teppo.p...@gmail.com wrote:
>> Generally, with testing, it would be optimal to test outputs of the
>> system for given inputs without caring how things are implemented.
>
> I disagree with that statement.
I, OTOH, agree with it.
> But in fact, that
On Wed, 9 Nov 2016 10:01 am, teppo.p...@gmail.com wrote:
> Generally, with testing, it would be optimal to test outputs of the system
> for given inputs without caring how things are implemented.
I disagree with that statement.
You are talking about "black-box testing" -- the test code should tr
On Wed, Nov 9, 2016 at 10:01 AM, wrote:
> One solution is:
>
> class Example:
> def __init__(self, queue=None):
> self._queue = queue or Queue()
>
> Fine approach, but technically __init__ has two execution branches and
> someone staring blindly coverages might require covering those
> How is having 15 arguments in a .create() method better than having 15
> arguments in __init__() ?
> So, if you use the create() method, and it sets up internal data structures,
> how do you test them? In other words, if create() makes that queue then how
> do you test with a half-empty queue
On 11/07/2016 12:46 AM, teppo.p...@gmail.com wrote:
torstai 3. marraskuuta 2016 14.45.49 UTC Ethan Furman kirjoitti:
On 11/03/2016 01:50 AM, teppo wrote:
The guide is written in c++ in mind, yet the concepts stands for any
programming language really. Read it through and think about it. If
>>
>> If the class in question has legitimate, non-testing, reasons to specify
>> different Queues, then make it a default argument instead:
>>
>> def __init__(self, ..., queue=None):
>> if queue is None:
>> queue = Queue()
>> self.queue = queue
>
> I already stated that this is
torstai 3. marraskuuta 2016 14.47.18 UTC Chris Angelico kirjoitti:
> On Thu, Nov 3, 2016 at 7:50 PM, wrote:
> > Little bit background related to this topic. It all starts from this
> > article:
> > http://misko.hevery.com/attachments/Guide-Writing%20Testable%20Code.pdf
> >
> > The guide is writt
torstai 3. marraskuuta 2016 14.45.49 UTC Ethan Furman kirjoitti:
> On 11/03/2016 01:50 AM, teppo wrote:
>
> > The guide is written in c++ in mind, yet the concepts stands for any
> > programming language really. Read it through and think about it. If
> > you come back to this topic and say: "yea
On 11/03/2016 07:45 AM, Ethan Furman wrote:
On 11/03/2016 01:50 AM, teppo.p...@gmail.com wrote:
The guide is written in c++ in mind, yet the concepts stands for any
programming language really. Read it through and think about it. If
you come back to this topic and say: "yeah, but it's c++", t
On Thu, Nov 3, 2016 at 7:50 PM, wrote:
> Little bit background related to this topic. It all starts from this article:
> http://misko.hevery.com/attachments/Guide-Writing%20Testable%20Code.pdf
>
> The guide is written in c++ in mind, yet the concepts stands for any
> programming language really.
On 11/03/2016 01:50 AM, teppo.p...@gmail.com wrote:
The guide is written in c++ in mind, yet the concepts stands for any
programming language really. Read it through and think about it. If
you come back to this topic and say: "yeah, but it's c++", then you
haven't understood it.
The ideas (
Hello everyone, I'll step into conversation too as I think it is quite
important topic. I'd be the one my collegue calls keen to this practice.
Little bit background related to this topic. It all starts from this article:
http://misko.hevery.com/attachments/Guide-Writing%20Testable%20Code.pdf
Th
On Thursday 03 November 2016 00:46, stest...@gmail.com wrote:
> Hi
>
> I was hoping to canvas opinion on using classmethods as constructors over
> __init__.
>
> We've got a colleague who is very keen that __init__ methods don't contain
> any logic/implementation at all, and if there is any, then
h at all.
Perhaps your collegue uses languages that do not have default arguments,
which make his alternative unnecessary for Python.
What do people feel about this?
AFAIK, the stdlib only has alternate constructor classmethods as
specialized alternatives to __init__, not as replacem
On 11/02/2016 06:46 AM, stest...@gmail.com wrote:
I was hoping to canvas opinion on using classmethods as constructors over
__init__.
We've got a colleague who is very keen that __init__ methods don't contain any
logic/implementation at all, and if there is any, then it should be moved to a
On Wednesday, November 2, 2016 at 1:47:00 PM UTC, stes...@gmail.com wrote:
> Hi
>
> I was hoping to canvas opinion on using classmethods as constructors over
> __init__.
>
> We've got a colleague who is very keen that __init__ methods don't contain
> any logic/implementation at all, and if ther
On Thu, Nov 3, 2016 at 12:46 AM, wrote:
> We've got a colleague who is very keen that __init__ methods don't contain
> any logic/implementation at all, and if there is any, then it should be moved
> to a create() classmethod.
>
> I get the underlying principal, and it's one that a strict OOp ap
Hi
I was hoping to canvas opinion on using classmethods as constructors over
__init__.
We've got a colleague who is very keen that __init__ methods don't contain any
logic/implementation at all, and if there is any, then it should be moved to a
create() classmethod.
As a concrete example, one
19 matches
Mail list logo
