testdrivendevelopment@groups.io

Re: [TDD] How do you go about splitting a class using TDD?

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

- Test-afterThe tests are written after the production code exists and probably also works. In other words, normal unit testing.

- Mutation testingThis is unrelated to how the tests were originally written. Mutation testing is when you make a small change to the production code and then run all tests, hoping that at least one test failed and thus found that mutation. The more mutations the tests find, the better.

Usually the mutating is done by an automated tool. The only usable mutation testing tool I know is  Its web site gives also a good explanation of what mutation testing is. There's also a Wikipedia page: 

Having 100% mutation coverage is a much higher guarantee of good tests than 100% line or branch coverage. It's possible to get 100% line coverage without writing a single assertion, without testing anything. But not so with mutation testing, which actually makes sure that the tests can catch problems.

-- 
Esko Luontola
www.orfjackal.net

Re: [TDD] How do you go about splitting a class using TDD?

Niels Krijger

#35119

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 referring to the following definitions:
- Test-first
- Mutation testing
- Test-after
I often can't really tell the difference between them. Would you hazard a
guess to their definitions?

I hope my reply doesn't take too much away from Kaleb's original post about
avoiding mocking helper-classes, an issue I've bothered with as well!
Regards,
Niels


2012/9/10 Esko Luontola <esko.luontola@...>

**


Kaleb Pederson wrote on 10.9.2012 19:39:

When I end up splitting a class, I've usually introduced another
collaborator and I need to do exactly what you describe here. That is,
I change each of the tests to use a mock for the newly introduced
collaborator.

Sometimes, the new collaborator is a helper or infrastructure-based
collaborator. That is, it's intended to make the code cleaner and
more reusable without actually changing the observable behavior. In
this case, the changes I've made would be considered "implementation
details," and I leave all the existing tests but introduce a new test
class for the new collaborator. In this case, the original class will
use the helper directly and I avoid mocking it out.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 feature that I
see. Through lots of TDD experience I'm able to know what tests I would
have written for it test-first, so I can write pretty much the same
tests test-after (maybe even better tests, because now I know exactly
what the code does; test-first needs some more test refactoring). Or if
it's easier, I'll refactor and move the old tests which cover the
extracted responsibilities.

After the new class has its tests in place, I have a look at the old
tests. If the responsibility was moved to the new class, I remove the
test. If a test can be made simpler by replacing the new class with a
test double, then I do it. Or if the tests are written in terms of the
old class and the extracted class is just an implementation detail, then
I keep the tests as-is.

As a safety net I use  for mutation testing. That will
let me find missing tests, in case I missed some corner case when doing
test-after. It might also be useful to run just the new tests and see
now well they cover the new class (though I'm not yet doing it - maybe
after there is an IDE plugin for PIT).

--
Esko Luontola
www.orfjackal.net



[Non-text portions of this message have been removed]

Re: [TDD] How do you go about splitting a class using TDD?

#35118

Kaleb Pederson wrote on 10.9.2012 19:39:
When I end up splitting a class, I've usually introduced another
collaborator and I need to do exactly what you describe here. That is,
I change each of the tests to use a mock for the newly introduced
collaborator.

Sometimes, the new collaborator is a helper or infrastructure-based
collaborator. That is, it's intended to make the code cleaner and
more reusable without actually changing the observable behavior. In
this case, the changes I've made would be considered "implementation
details," and I leave all the existing tests but introduce a new test
class for the new collaborator. In this case, the original class will
use the helper directly and I avoid mocking it out.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 feature that I see. Through lots of TDD experience I'm able to know what tests I would have written for it test-first, so I can write pretty much the same tests test-after (maybe even better tests, because now I know exactly what the code does; test-first needs some more test refactoring). Or if it's easier, I'll refactor and move the old tests which cover the extracted responsibilities.

After the new class has its tests in place, I have a look at the old tests. If the responsibility was moved to the new class, I remove the test. If a test can be made simpler by replacing the new class with a test double, then I do it. Or if the tests are written in terms of the old class and the extracted class is just an implementation detail, then I keep the tests as-is.

As a safety net I use  for mutation testing. That will let me find missing tests, in case I missed some corner case when doing test-after. It might also be useful to run just the new tests and see now well they cover the new class (though I'm not yet doing it - maybe after there is an IDE plugin for PIT).

-- 
Esko Luontola
www.orfjackal.net

Re: [TDD] How do you go about splitting a class using TDD?

#35117

On Sep 10, 2012, at 5:34 AM, arnonaxelrod <arnonaxelrod@...> wrote:
My problems is as follows:
...
after some time I realize that one of the classes
has multiple responsibilities and it needs to be refactored and split it
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 then came up with some *correct* class diagrams, sequence diagrams, activity diagrams, etc, then you would have gotten the code right the first time and never have had to change ... whoops, wrong list.


---
Nayan Hajratwala - 734.658.6032 -  - @nhajratw

Re: [TDD] How do you go about splitting a class using TDD?

John Goodsen

#35116

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 dependencies).... so I do have
some broken code for sometimes a *LONG* time (long time is like 10 minutes
or so)...

Along the way, I mock out the A2 dependencies in the original test.

You might also play around with Mockito's  doCallRealMethod() and partially
mock the A2 or A1 aspects of the object to help isolate the A1 and A2 tests
into 2 groups, before you refactor the A2 tests to a new class.

I have a card to do this type of refactoring tomorrow.  I'll play with it
and report back if something interesting occurs...

jg

Show quoted text

On Mon, Sep 10, 2012 at 9:48 AM, Angel Java Lopez <ajlopez2000@...>wrote:

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 responsibility R2, to
reach A2.
Then, remove R2-related code from class A.
Rename A to A1.

But maybe I'm thinking in a clear separation btw R1, R2.

The part I was unable to understand: do you have tests that exercise
BOTH responsibilities? Any concrete example?
Is any A method that uses BOTH responsibilities?

On Mon, Sep 10, 2012 at 6:34 AM, arnonaxelrod <arnonaxelrod@...
wrote:**



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 hear other's opinions.

My problems is as follows:
Even though in general TDD helps me think of the core responsibility of
a class, and extract every other responsibility to dependent classes,
there are cases that after some time I realize that one of the classes
has multiple responsibilities and it needs to be refactored and split it
into 2 classes. This conclusion often comes because the tests of that
class start to become complicated or repetitive. I can pretty easily do
refactoring to split this class to the design I want (and I do it in
small steps, keeping on the green bar). My problem is that I end up with
the same complicated and repetitive tests that now tests the 2 classes
together, while I would like to have seperate tests for each class.
The only (more-or-less safe) manner I could think of for doing that, is
to do the following for each test (after I completed the refactoring of
the production code):

1. Duplicate the test case
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 mock instead of the 2nd
class.
3. Then if I see that an identical test already exists for one of the
copies, I delete it.

I think that sometimes its possible to do the following:

1. start by creating the 2 classes from scratch (using TDD of course)
2. Change the old tests to use the new classes instead of the old one
3. Delete the old class
4. Delete the old tests

Both of these techniques seems pretty cumbersome and time consuming, so
I wonder: how do the "real experts" go about this issue?









------------------------------------

Yahoo! Groups Links

-- 
John Goodsen                 RADSoft / Better Software Faster
jgoodsen@...            Lean/Kanban/XP/Scrum Coaching and Training
          Enterprise Ruby, Java and Scala Solutions

Re: [TDD] How do you go about splitting a class using TDD?

#35115

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 mock instead of the 2nd
class.When I end up splitting a class, I've usually introduced another
collaborator and I need to do exactly what you describe here. That is,
I change each of the tests to use a mock for the newly introduced
collaborator.

Sometimes, the new collaborator is a helper or infrastructure-based
collaborator.  That is, it's intended to make the code cleaner and
more reusable without actually changing the observable behavior. In
this case, the changes I've made would be considered "implementation
details," and I leave all the existing tests but introduce a new test
class for the new collaborator. In this case, the original class will
use the helper directly and I avoid mocking it out.

For example, I had a bunch of repetitive code in a few classes that
were dispatching events that contained timing and success/failure
information about event processing. To the collaborators of these
classes, they cared only that the events contained the correct
information, not how the event was obtained. So, I left all the tests
that I had, encapsulating the internal implementation details, and
added a new test class that validated my helper worked as intended.

HTH,

--Kaleb

Re: [TDD] How do you go about splitting a class using TDD?

#35114

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 responsibility R2, to
reach A2.
Then, remove R2-related code from class A.
Rename A to A1.

But maybe I'm thinking in a clear separation btw R1, R2.

The part I was unable to understand: do you have tests that exercise
BOTH responsibilities? Any concrete example?
Is any A method that uses BOTH responsibilities?

Show quoted text

On Mon, Sep 10, 2012 at 6:34 AM, arnonaxelrod <arnonaxelrod@...>wrote:

**



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 hear other's opinions.

My problems is as follows:
Even though in general TDD helps me think of the core responsibility of
a class, and extract every other responsibility to dependent classes,
there are cases that after some time I realize that one of the classes
has multiple responsibilities and it needs to be refactored and split it
into 2 classes. This conclusion often comes because the tests of that
class start to become complicated or repetitive. I can pretty easily do
refactoring to split this class to the design I want (and I do it in
small steps, keeping on the green bar). My problem is that I end up with
the same complicated and repetitive tests that now tests the 2 classes
together, while I would like to have seperate tests for each class.
The only (more-or-less safe) manner I could think of for doing that, is
to do the following for each test (after I completed the refactoring of
the production code):

1. Duplicate the test case
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 mock instead of the 2nd
class.
3. Then if I see that an identical test already exists for one of the
copies, I delete it.

I think that sometimes its possible to do the following:

1. start by creating the 2 classes from scratch (using TDD of course)
2. Change the old tests to use the new classes instead of the old one
3. Delete the old class
4. Delete the old tests

Both of these techniques seems pretty cumbersome and time consuming, so
I wonder: how do the "real experts" go about this issue?

[Non-text portions of this message have been removed]

How do you go about splitting a class using TDD?

#35113

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 hear other's opinions.

My problems is as follows:
Even though in general TDD helps me think of the core responsibility of
a class, and extract every other responsibility to dependent classes,
there are cases that after some time I realize that one of the classes
has multiple responsibilities and it needs to be refactored and split it
into 2 classes. This conclusion often comes because the tests of that
class start to become complicated or repetitive. I can pretty easily do
refactoring to split this class to the design I want (and I do it in
small steps, keeping on the green bar). My problem is that I end up with
the same complicated and repetitive tests that now tests the 2 classes
together, while I would like to have seperate tests for each class.
The only (more-or-less safe) manner I could think of for doing that, is
to do the following for each test (after I completed the refactoring of
the production code):

    1. Duplicate the test case
    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 mock instead of the 2nd
class.
    3. Then if I see that an identical test already exists for one of the
copies, I delete it.

I think that sometimes its possible to do the following:

    1. start by creating the 2 classes from scratch (using TDD of course)
    2. Change the old tests to use the new classes instead of the old one
    3. Delete the old class
    4. Delete the old tests

Both of these techniques seems pretty cumbersome and time consuming, so
I wonder: how do the "real experts" go about this issue?

Request to participate in a research study regarding the performance appraisal of software testers.

#35112

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 (jgrundy@...) and Dr. Robert Merkel (robert.merkel@...) and I (tkanij@...) are conducting a study to collect information about the current
practice of performance appraisal of software testers in industry. We also plan
to evaluate a proposed Performance Appraisal Form (PAF) for software testers.
In this study, we hope to get responses from professionals who
manage software testers. The project is approved by Swinburne University Human
Research Ethics Subcommittee.

The study is an
online survey that should take around 40 minutes to complete. No association
between your responses and any identifying details will be retained.?After
the successful completion of the survey we hope to have an idea of the state of
the practice of performance appraisal of software testers, and will publish
these results through peer-reviewed conferences and/or journals.? This will benefit practitioners by informing
them about broader industry practices for appraisal method, as well as
benefiting research in the area to try and design better appraisal methods. The
study will also validate a novel proposed Performance Appraisal Form (PAF) for
testers. The validated PAF may be useful as a basis for appraising performance
of testers in industry, as well as in academic research requiring performance
assessment of testers.

We invite managers of
software testers to participate in the research study. As a manager your
participation in the research study will add deep insight into the available
knowledge on performance appraisal of software testers and will be helpful to
evaluate the proposed performance appraisal form for testers.

If you would like to participate or
have further queries regarding the research study, please email me (tkanij@...).
?
Best Regards
Tanjila Kanij
PhD candidate
Faculty of Information and Communication Technologies
Swinburne University of Technology.

[Non-text portions of this message have been removed]