开云体育

Niels Krijger wrote on 11.9.2012 0:01: The tests are written (one at a time) before the the production code which passes them. In other words, TDD. The tests are written after the production code

Hi Esko, Sorry this is quite off-topic. You (Esko) seem to have a very clear grasp on the definitions used in your reply which made it a bit confusing to interpret your message. In particular I'm

Kaleb Pederson wrote on 10.9.2012 19:39: I'm doing it similar to Kaleb. After extracting the new class, I look at its code to see what are its responsibilities/features, and then write tests for each

I never actually have this problem, and it sounds to me like you have a problem with your process. You see, if you just spent some more time on making sure you got the requirements exactly right and

I kinda do it like Angel, except when I write A2 using TDD, it is a process of moving each test specific to the behavior to A2Test and rewriting it (probably cleaner, with less mocking and

On Mon, Sep 10, 2012 at 2:34 AM, arnonaxelrod <arnonaxelrod@...> wrote: ... > 2. Change one copy of the test to use a mock instead of the 1st > class, and the other copy of the test to use a

Hmmm.... Let A the original class. Let A1, A2 your imagined new classes, attending responsibilities R1, R2. I would write A2, using TDD. Then, re-factor the original tests that exercises

Hi all, I feel pretty skilled in TDD, and I'm even consired the "TDD expert" in my company, but nevertheless, there are some cases that I feel I don't know how to handle properly, so I would like to

Dear Members, ? I’m a PhD student in Faculty of Information and Communication Technologies, Swinburne University of Technology. As a project of my PhD thesis, my supervisorsProfessor John Grundy

I'm off. I'll check for further answers tomorrow. Thanks a lot =)

Smart ! I thought that Test::Class was mostly used to inherits unit-tests from a class into its subclasses. And overload some of them when needed. But you're right, it could also enable to subclass

Hi Ron, my message of 6:30pm (in england - it was 14 minutes before your message) answers this question with a simple example. My aim is simply to put bits of tests into a function, to avoid

Or, a non-OO alternative would be to put played_with in a module of its own and call it from each different test module. That might be simpler to start, but you should still check out Test:Class,

You can subclass your tests. Nothing wrong with that. Check this out: http://search.cpan.org/~adie/Test-Class-0.37/lib/Test/Class.pm

Why do you have these sugar methods? What do they do? Why can't you test the Vehicle directly? R Ron Jeffries www.XProgramming.com Impossible is not a fact. It is an opinion. -- Muhammad Ali

Nope, i don't want to know about bits inside of $game. I'm just trying to avoid to have to copy-paste played_with() in each test file. Maybe i should just have a package in my unit-test folder, where

P.S. the ONLY reason I would put played_with in a subclass of $game is if it needed to know about private bits inside of $game. However, actually hiding members in Perl 5 turns out to be nearly

My perl is a tad rusty, but I would recommend you just keep the played_with() sub in the test. The only difference is you'd have to call it differently: played_with($game, @rolls); Subclassing $game

For the first case (without assertion), i could put the played_with() method in an instance (a role, in Perl). If i left it in the test file, that would become a problem as soon as i will have several

I'm learning Perl and TDD. I'm thinking both about methods that will "run a fairly similar part of several test cases", and about methods who will be tests by themself : they will contain assertions.