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
On 11/2/2016 9:46 AM, 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 it should be moved to a
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
18 matches
Mail list logo
