Home > Archive > Extreme Programming > April 2004 > Re: Code Coverage and QC
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: Code Coverage and QC
|
|
| Anthony Williams 2004-03-18, 6:54 pm |
| "Vladimir Trushkin" <NspamOtrushkin@tut.by> writes:
> You are obviously confusing structured and behavioral testing activities.
Quite possibly. I am airing my ignorance in public in order to learn.
> They have different classes of defect to trigger. Not all of design
> decisions map directly into functionality. Some of aspects of system design
> may be invisible, obscured if viewed from functional perspective. This is
> when code coverage comes to play to help us improve testing as to make sure
> that there will be no path in the code not examined for correctness.
I understand your words, but not the reason behind them. If there are aspects
of the system design which are "invisible, obscured if viewed from the
functional perspective", what purpose are they serving?
Surely the purpose of the application is to perform some function, and any
code which does not contribute to the performing of that function is
extraneous. I include code that contributes to making the function easier,
faster or more pleasant to perform from the user perspective as contributing
to the function of the application; it is also quite clearly visible from a
functional perspective.
> the
>
> Normal use may vary.
True. So you work closely with all your customers to determine how they intend
to use the system.
> You can't predict all the possible defects up-front.
If you could, software development would be a lot easier.
Anthony
--
Anthony Williams
Senior Software Engineer, Beran Instruments Ltd.
| |
| Kevin Cline 2004-03-18, 6:54 pm |
| "Vladimir Trushkin" <NspamOtrushkin@tut.by> wrote in message news:<c2jvk7$1b7$1@news.gngidc.net>...
> "Kevin Cline" <kcline17@hotmail.com> wrote in message
> news:ba162549.0403081026.1037f365@posting.google.com...
> news:<c2a96n$jaq$1@news.gngidc.net>...
> activities.
> design
> is
> sure
>
> I mean both, including logical branching caused by using operands like if()
> and loops.
>
>
> Yes, but studies have shown that even statement coverage achieved was
> incomplete, so the testing has left the holes in code not examined.
>
>
> Can't agree with you on that. I doubt anyone would write
>
> if(A>0) {
> if( B>0) {
> if(C>0) {
> ...
> }
> }
> }
>
> instead of
>
> if( A>0 && B>0 && C>0 ) {
> ...
> }
No, but they might write:
for (...) {
if (...) {
for (...) {
}
else {
...
}
}
if (...)
{
...
}
else {
...
}
That code has high path complexity. But if you refactor it into short
routines:
A() {
for (...) { B(...); }
E(...);
}
B(){
if (...) {
C(...);
}
else D(...);
}
C() {
for (...) {}
}
D() {
...
}
E() {
if (...) { ... } else { ... }
}
Then the number of paths through each routine is very small, like two,
and there is little or no difference between statement coverage and
path coverage. Since the routines interact only by their arguments,
it becomes a relatively simple matter to verify such code by
inspection, or even to formally prove it correct.
| |
| Donald Roby 2004-03-19, 1:17 pm |
| On Tue, 09 Mar 2004 10:35:15 +0200, Vladimir Trushkin wrote:
> Can't agree with you on that. I doubt anyone would write
>
> if(A>0) {
> if( B>0) {
> if(C>0) {
> ...
> }
> }
> }
> }
> instead of
>
> if( A>0 && B>0 && C>0 ) {
> ...
> }
> }
> }
Actually, I can imagine doing that, if I were working with a language
without shortcut boolean evaluation, and if I were concerned about
efficiency.
| |
| Universe 2004-03-19, 1:17 pm |
|
"Donald Roby" <droby@acm.org> wrote in message
news:pan.2004.03.19.02.30.12.922269@acm.org...
> On Tue, 09 Mar 2004 10:35:15 +0200, Vladimir Trushkin wrote:
>
>
> Actually, I can imagine doing that, if I were working with a language
> without shortcut boolean evaluation, and if I were concerned about
> efficiency.
I tend to write like the first for *readability*. I started often with the
latter,
but I get greater chills, and thrills from elegant design and architected
and from
overall code look and appeal.
The 1st "looks" better, imo.
Elliott
| |
| David Lightstone 2004-03-19, 1:17 pm |
|
"Anthony Williams" <anthony_w.geo@yahoo.com> wrote in message
news:y8pxur15.fsf@yahoo.com...
> "Universe" <universe@tAkEcovadOuT.net> writes:
>
Thats funny, I would write it as
{
unsigned a;
a = 0;
if(A>0)
{
a = 1;
}
if( B>0)
{
a |= 2;
}
if(C>0)
{
a |= 4;
}
if ( a == 7)
{
do_something;
}
else
{
}
}
Any good optimizer will eliminate the variable a, unless is is declared
volatile.
My guess is the expression order evaluation is fixed with the nested if
version, whereas in the logical expression version the compliler probably
gets to choose the order.
Now suppose in one of your test scenarios do_something doesn't get called
when you believe it should
Care to guess which variation will be easier to debug
Order does count when time is critical
[color=darkred]
the[color=darkred]
architected[color=darkred]
>
> On precisely the same principle, I would write the latter. The "..." is
> executed if all three conditions are true, which the second example makes
> explicit, whereas the first example has me searching for "else" clauses.
>
> I guess it's a matter of preference.
>
> Anthony
> --
> Anthony Williams
> Senior Software Engineer, Beran Instruments Ltd.
| |
| Randy at Home 2004-03-19, 1:17 pm |
| "David Lightstone" <david._NoSpamlightstone@prodigy.net> wrote in message
news:3eB6c.26977$i_4.5413@newssvr31.news.prodigy.com...
|
| "Anthony Williams" <anthony_w.geo@yahoo.com> wrote in message
| news:y8pxur15.fsf@yahoo.com...
| > "Universe" <universe@tAkEcovadOuT.net> writes:
| >
| > >> On Tue, 09 Mar 2004 10:35:15 +0200, Vladimir Trushkin wrote:
| > >>
| > >>
| > >> > Can't agree with you on that. I doubt anyone would write
| > >> >
| > >> > if(A>0) {
| > >> > if( B>0) {
| > >> > if(C>0) {
| > >> > ...
| > >> > }
| > >> > }
| > >> > }
| > >> > }
| > >> > instead of
| > >> >
| > >> > if( A>0 && B>0 && C>0 ) {
| > >> > ...
| > >> > }
| > >> > }
| > >> > }
|
| Thats funny, I would write it as
| {
| unsigned a;
| a = 0;
| if(A>0)
| {
| a = 1;
| }
| if( B>0)
| {
| a |= 2;
| }
| if(C>0)
| {
| a |= 4;
| }
| if ( a == 7)
| {
| do_something;
| }
| else
| {
| }
| }
| Any good optimizer will eliminate the variable a, unless is is declared
| volatile.
| My guess is the expression order evaluation is fixed with the nested if
| version, whereas in the logical expression version the compliler probably
| gets to choose the order.
|
| Now suppose in one of your test scenarios do_something doesn't get called
| when you believe it should
| Care to guess which variation will be easier to debug
|
| Order does count when time is critical
Another bit that's important is to ensure that complex boolean expressions
are fully evaluated. Most optimizers will do early exits out of a boolean
expression where an answer is known (e.g., A > 0 && B > 0 ... if A < 0 then
B > 0 is not executed). Code coverage must include complete evaluation of
these. Analyzers that only say that a line of code is executed isn't
sufficient to ensure that it actually was, in such conditions.
| |
| Poutanen Olavi 2004-03-19, 1:17 pm |
| In comp.software-eng Randy at Home <rsbecker_whatever@hotmail.com_nospam_atall> wrote:
....snip
: Another bit that's important is to ensure that complex boolean expressions
: are fully evaluated. Most optimizers will do early exits out of a boolean
: expression where an answer is known (e.g., A > 0 && B > 0 ...
If this is C or C++, doesn't this come enforced from language definition, not
from a possible compiler optimizer decision.
: if A < 0 then
: B > 0 is not executed).
What happens if A == 0 ? ;)
: Code coverage must include complete evaluation of
: these. Analyzers that only say that a line of code is executed isn't
: sufficient to ensure that it actually was, in such conditions.
Agreed.
Olavi
| |
| David Lightstone 2004-03-19, 8:40 pm |
|
"Randy at Home" <rsbecker_whatever@hotmail.com_nospam_atall> wrote in
message
news:wxD6c.68616$uUx1.9584@twister01.bloor.is.net.cable.rogers.com...
> "David Lightstone" <david._NoSpamlightstone@prodigy.net> wrote in message
> news:3eB6c.26977$i_4.5413@newssvr31.news.prodigy.com...
> |
> | "Anthony Williams" <anthony_w.geo@yahoo.com> wrote in message
> | news:y8pxur15.fsf@yahoo.com...
> | > "Universe" <universe@tAkEcovadOuT.net> writes:
> | >
> | > >> On Tue, 09 Mar 2004 10:35:15 +0200, Vladimir Trushkin wrote:
> | > >>
> | > >>
> | > >> > Can't agree with you on that. I doubt anyone would write
> | > >> >
> | > >> > if(A>0) {
> | > >> > if( B>0) {
> | > >> > if(C>0) {
> | > >> > ...
> | > >> > }
> | > >> > }
> | > >> > }
> | > >> > }
> | > >> > instead of
> | > >> >
> | > >> > if( A>0 && B>0 && C>0 ) {
> | > >> > ...
> | > >> > }
> | > >> > }
> | > >> > }
> |
> | Thats funny, I would write it as
> | {
> | unsigned a;
> | a = 0;
> | if(A>0)
> | {
> | a = 1;
> | }
> | if( B>0)
> | {
> | a |= 2;
> | }
> | if(C>0)
> | {
> | a |= 4;
> | }
> | if ( a == 7)
> | {
> | do_something;
> | }
> | else
> | {
> | }
> | }
> | Any good optimizer will eliminate the variable a, unless is is declared
> | volatile.
> | My guess is the expression order evaluation is fixed with the nested if
> | version, whereas in the logical expression version the compliler
probably
> | gets to choose the order.
> |
> | Now suppose in one of your test scenarios do_something doesn't get
called
> | when you believe it should
> | Care to guess which variation will be easier to debug
> |
> | Order does count when time is critical
>
> Another bit that's important is to ensure that complex boolean expressions
> are fully evaluated. Most optimizers will do early exits out of a boolean
> expression where an answer is known (e.g., A > 0 && B > 0 ... if A < 0
then
> B > 0 is not executed). Code coverage must include complete evaluation of
> these. Analyzers that only say that a line of code is executed isn't
> sufficient to ensure that it actually was, in such conditions.
>
>
I wonder which type of code coverage has the official blessing of the Agile
Movement.
My guess would be statement/line coverage.
| |
| John Roth 2004-03-26, 11:50 pm |
| "David Lightstone" <david._NoSpamlightstone@prodigy.net> wrote in message
news:oZL6c.37327$eO6.36186@newssvr16.news.prodigy.com...
> I wonder which type of code coverage has the official blessing of the
Agile
> Movement.
> My guess would be statement/line coverage.
I wouldn't know what the "official blessing" would look
like. It's a demonstrated fact that TDD, correctly applied,
will result in very high (high 90s) statement and branch
coverage without additional effort. That doesn't constitute
an "official blessing" or even any statement that those
metrics have any special cachet. It's simply an observed
fact.
Whether that's adequate depends, I suspect, on
exactly how clean you want the result to be, and
how certain you want to be that you'll get there.
I believe that it's substantially more than any other
technique will get you unless it's backed up by a
measurement program.
John Roth
>
>
| |
| David Lightstone 2004-03-26, 11:50 pm |
|
"John Roth" <newsgroups@jhrothjr.com> wrote in message
news:105n7rian8a71cd@news.supernews.com...
> "David Lightstone" <david._NoSpamlightstone@prodigy.net> wrote in message
> news:oZL6c.37327$eO6.36186@newssvr16.news.prodigy.com...
>
> Agile
>
>
> I wouldn't know what the "official blessing" would look
> like. It's a demonstrated fact that TDD, correctly applied,
> will result in very high (high 90s) statement and branch
> coverage without additional effort. That doesn't constitute
> an "official blessing" or even any statement that those
> metrics have any special cachet. It's simply an observed
> fact.
I think you are a bit  . The subject is not whether TDD achieves
"high" coverage, but
(1) Whether statement coverage is adequate
(2) Which version (Statement or path/branch) of coverage is being advocated
by the Agile Alliance
>
> Whether that's adequate depends, I suspect, on
> exactly how clean you want the result to be, and
> how certain you want to be that you'll get there.
> I believe that it's substantially more than any other
> technique will get you unless it's backed up by a
> measurement program.
Ask your manager how clean it need to be. Anyone willing to belief he will
say 80% clean? What about 90% clean?
are further guesses needed?
>
> John Roth
>
>
| |
| John Roth 2004-03-26, 11:50 pm |
| "David Lightstone" <david._NoSpamlightstone@prodigy.net> wrote in message
news:0mW6c.27193$Px7.25673@newssvr31.news.prodigy.com...
>
> "John Roth" <newsgroups@jhrothjr.com> wrote in message
> news:105n7rian8a71cd@news.supernews.com...
message[color=darkred]
>
> I think you are a bit . The subject is not whether TDD achieves
> "high" coverage, but
> (1) Whether statement coverage is adequate
Since the only message in the XP newsgroup is the
one you just crossposted from an existing thread in
another newsgroup, how am I to guess that this
was an issue?
> (2) Which version (Statement or path/branch) of coverage is being
advocated
> by the Agile Alliance
None. That's what I said.
John Roth
| |
| David Lightstone 2004-03-26, 11:50 pm |
|
"John Roth" <newsgroups@jhrothjr.com> wrote in message
news:105oegitckgtdb8@news.supernews.com...
> "David Lightstone" <david._NoSpamlightstone@prodigy.net> wrote in message
> news:0mW6c.27193$Px7.25673@newssvr31.news.prodigy.com...
> message
the[color=darkred]
Very well I will accept 90% statement coverage. I will treat the "and branch
coverage" as misinformation.
[color=darkred]
>
> Since the only message in the XP newsgroup is the
> one you just crossposted from an existing thread in
> another newsgroup, how am I to guess that this
> was an issue?
The entire thread has been posted to comp.software.exreem-prog, you are
mistaken about my having crossposted it.
>
> advocated
>
> None. That's what I said.
Interesting.
>
> John Roth
>
>
| |
| John Roth 2004-03-26, 11:50 pm |
|
"David Lightstone" <david._NoSpamlightstone@prodigy.net> wrote in message
news:Wn47c.37694$kB2.37370@newssvr16.news.prodigy.com...
>
> "John Roth" <newsgroups@jhrothjr.com> wrote in message
> news:105oegitckgtdb8@news.supernews.com...
message[color=darkred]
> the
>
> Very well I will accept 90% statement coverage. I will treat the "and
branch
> coverage" as misinformation.
Why? I meant what I said. To expand on it a bit:
Measurements indicate that applying TDD properly
will result in statement coverate in the upper 90%, and
branch coverage in the lower 90% range.
As it turns out, there are good theoretical justifications
for this, but we worked them out after noticing the
measurement results.
achieves[color=darkred]
Adequate for what? Most of the agile people I know
would ask that question first. For many projects, it's
probably quite adequate. For others, it's probably
completely inadequate.
In any case, any type of code quality metric is a
secondary indicator. As far as I'm concerned, there
are only two primary metrics that matter: whether
the code can sustain a constant (or possibly increasing)
velocity, and whether the delivered product meets the
quality goals in actual usage.
Secondary metrics are interesting only to the extent
that they help me to get one or the other of the
two primary goals.
John Roth
[color=darkred]
>
>
>
| |
| David Lightstone 2004-03-26, 11:50 pm |
|
"John Roth" <newsgroups@jhrothjr.com> wrote in message
news:105q1cdkuhphf9@news.supernews.com...
>
> "David Lightstone" <david._NoSpamlightstone@prodigy.net> wrote in message
> news:Wn47c.37694$kB2.37370@newssvr16.news.prodigy.com...
> message
of[color=darkred]
> branch
>
> Why? I meant what I said. To expand on it a bit:
> Measurements indicate that applying TDD properly
> will result in statement coverate in the upper 90%, and
> branch coverage in the lower 90% range.
>
> As it turns out, there are good theoretical justifications
> for this, but we worked them out after noticing the
> measurement results.
Did "we" also publish them in a reputable journal?
>
> achieves
>
> Adequate for what? Most of the agile people I know
> would ask that question first. For many projects, it's
> probably quite adequate. For others, it's probably
> completely inadequate.
I guess the agile people with whom you are in contact do not include the
managers who ask such 2 part questions as -
What percentage of your code has been tested, 70%, 80%, 90%, 95%, 97.5%?
Upon what basis do you make that completion claim?
Are not there effort heuristics that go something like the final 10% of the
effort consumes X% of the budget? (with X being subject to vigerous and
fruitless debate without substanciating statistics)
You say low 90% branch coverage. So I guess that means all the easy work has
been done, and the heavy lifting remains to be done. So when the XP project
is done, the remaining financial burdon can be estimated (based upon the
cost previously incured), right?
>
> In any case, any type of code quality metric is a
> secondary indicator. As far as I'm concerned, there
> are only two primary metrics that matter: whether
> the code can sustain a constant (or possibly increasing)
> velocity, and whether the delivered product meets the
> quality goals in actual usage.
I'm certain there has been vigrous disagreement about the validity of your
believe. For the present other than not the subjective nature of belief, I
shall only indicate disagreement
>
> Secondary metrics are interesting only to the extent
> that they help me to get one or the other of the
> two primary goals.
>
>
> John Roth
>
>
>
| |
| Vladimir Trushkin 2004-03-26, 11:50 pm |
| "Donald Roby" <droby@acm.org> wrote in message
news:pan.2004.03.19.02.30.12.922269@acm.org...
> On Tue, 09 Mar 2004 10:35:15 +0200, Vladimir Trushkin wrote:
>
>
> Actually, I can imagine doing that, if I were working with a language
> without shortcut boolean evaluation, and if I were concerned about
> efficiency.
The question remains how often you actually do it.
----
Best Wishes,
Vladimir
P.S. What you are not testing for doesn't exists.
| |
| Vladimir Trushkin 2004-03-26, 11:50 pm |
| "David Lightstone" <david._NoSpamlightstone@prodigy.net> wrote in message
news:oZL6c.37327$eO6.36186@newssvr16.news.prodigy.com...[color=darkred]
>
> "Randy at Home" <rsbecker_whatever@hotmail.com_nospam_atall> wrote in
> message
> news:wxD6c.68616$uUx1.9584@twister01.bloor.is.net.cable.rogers.com...
message[color=darkred]
[color=darkred]
> called
Exactly. Both getting into the statement and passing by it may contain an
error. Examining only in-sides is not enough, and this is exactly what
statement coverage is about.
----
Best Wishes,
Vladimir
| |
| Vladimir Trushkin 2004-03-26, 11:50 pm |
| "John Roth" <newsgroups@jhrothjr.com> wrote in message
news:105n7rian8a71cd@news.supernews.com...
> "David Lightstone" <david._NoSpamlightstone@prodigy.net> wrote in message
> news:oZL6c.37327$eO6.36186@newssvr16.news.prodigy.com...
>
> I wouldn't know what the "official blessing" would look
> like. It's a demonstrated fact that TDD, correctly applied,
> will result in very high (high 90s) statement and branch
> coverage without additional effort.
We were said that it was _approximately_ 100% of Statement coverage so far.
So, I can't believe this may do as much as 90s of Condition coverage. This
only could happen if your code straight with almost no logical branching.
Can you give us the source of this information?
----
Best Wishes,
Vladimir
| |
| Ronald E Jeffries 2004-03-26, 11:50 pm |
| On Sun, 21 Mar 2004 13:24:12 +0200, "Vladimir Trushkin"
<NspamOtrushkin@tut.by> wrote:
>
>We were said that it was _approximately_ 100% of Statement coverage so far.
>So, I can't believe this may do as much as 90s of Condition coverage. This
>only could happen if your code straight with almost no logical branching.
>
>Can you give us the source of this information?
If every single line of code was written only if it was necessary to
make a test pass, what would be the resulting coverage, statement,
branch, and any other of interest?
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
| |
| Donald Roby 2004-03-26, 11:50 pm |
| On Sun, 21 Mar 2004 13:11:07 +0200, Vladimir Trushkin wrote:
> "Donald Roby" <droby@acm.org> wrote in message
> news:pan.2004.03.19.02.30.12.922269@acm.org...
>
> The question remains how often you actually do it.
>
>
Personally, I don't do it at all these days. I write the conjunction, as
I think it's much clearer. My current primary language does support the
shortcut evaluation.
| |
| John Roth 2004-03-26, 11:50 pm |
|
"Vladimir Trushkin" <NspamOtrushkin@tut.by> wrote in message
news:c3ju1b$dhc$1@news.gngidc.net...
> "John Roth" <newsgroups@jhrothjr.com> wrote in message
> news:105n7rian8a71cd@news.supernews.com...
message[color=darkred]
>
>
> We were said that it was _approximately_ 100% of Statement coverage so
far.
> So, I can't believe this may do as much as 90s of Condition coverage. This
> only could happen if your code straight with almost no logical branching.
>
> Can you give us the source of this information?
Measurements as reported on the mailing list and the newsgroups.
John Roth
>
> ----
> Best Wishes,
> Vladimir
>
>
| |
| John Roth 2004-03-26, 11:50 pm |
|
"David Lightstone" <david._NoSpamlightstone@prodigy.net> wrote in message
news:jLd7c.37738$xA5.841@newssvr16.news.prodigy.com...
>
> "John Roth" <newsgroups@jhrothjr.com> wrote in message
> news:105q1cdkuhphf9@news.supernews.com...
message[color=darkred]
in[color=darkred]
> of
>
> Did "we" also publish them in a reputable journal?
No.
>
>
> I guess the agile people with whom you are in contact do not include the
> managers who ask such 2 part questions as -
> What percentage of your code has been tested, 70%, 80%, 90%, 95%, 97.5%?
> Upon what basis do you make that completion claim?
I've run across such managers. Since the Agile
Invariant is that there will be a production quality
deployable at the end of every iteration, the answer
at the end of the iteration is: 100% by definition.
If you aren't doing that, you aren't doing Agile
regardless of what you say you are doing.
> Are not there effort heuristics that go something like the final 10% of
the
> effort consumes X% of the budget? (with X being subject to vigerous and
> fruitless debate without substanciating statistics)
I'm well aware of them. That does indeed apply to
the requirements, which is why all agile methodologies
I'm aware of sort the requirements by order of decreasing
business value, and cut the development process off
when you hit the law of diminishing returns.
This does, of course, depend on using a short
cycle incremental development system.
> You say low 90% branch coverage. So I guess that means all the easy work
has
> been done, and the heavy lifting remains to be done. So when the XP
project
> is done, the remaining financial burdon can be estimated (based upon the
> cost previously incured), right?
Since it's gotten to as a byproduct of doing something
else which is valuable in its own right, I'd have to
agree with the first two sentences.
I would, however, disagree strongly with the third
sentence: if there is a requirement for any particular
metric to meet a specific goal, it's best done as an
ongoing part of the project, not to wait until it's done.
Note that this ties in with the answer to the previous
paragraph: at the end of the iteration, the result is a
production quality deployable. If you require that the
code satisfy some particular metric, that's part of the
definition of "production quality" for that project.
>
> I'm certain there has been vigrous disagreement about the validity of your
> believe. For the present other than not the subjective nature of belief, I
> shall only indicate disagreement
Only from people who are fanatically opposed to
the possibility of it being true. The rest of the
people will check it out for themselves. Note the
emphasis on the word "fanatic", which goes to the
basis of the person's belief system. I've frequently
observed that this seems to be tied into either their
financial or professional status.
John Roth
>
>
>
| |
| Leif Roar Moldskred 2004-03-26, 11:50 pm |
| Ronald E Jeffries <ronjeffries@acm.org> writes:
> If every single line of code was written only if it was necessary to
> make a test pass, what would be the resulting coverage, statement,
> branch, and any other of interest?
Assuming that is true for the original code-lines, what guarantee do
you have that it is still true after refactoring the code? How can you
show that your refactoring is correct, and didn't leave any dead code
around or that there are still no untested pathways through your code?
--
Leif Roar Moldskred
| |
| Vladimir Trushkin 2004-03-26, 11:50 pm |
| "John Roth" <newsgroups@jhrothjr.com> wrote in message
news:105r2911h1okp32@news.supernews.com...
>
> "Vladimir Trushkin" <NspamOtrushkin@tut.by> wrote in message
> news:c3ju1b$dhc$1@news.gngidc.net...
> message
> far.
This[color=darkred]
branching.[color=darkred]
>
> Measurements as reported on the mailing list and the newsgroups.
What about exact numbers? Was there a single measurement or a set of studies
with different product and within different XP installations? Ho consistent
are numbers reported by different XP groups? What type of coverage was it,
branch (decision) or condition?
Measurements should be used not only to justify you've done enough Unit
testing, but as a feedback on how you may improve your tests to be more
thorough. The problem with XP is that it badly fits into test-first concept.
----
Best Wishes,
Vladimir
| |
| Vladimir Trushkin 2004-03-26, 11:50 pm |
| "Leif Roar Moldskred" <rmoldskr+usenet@online.no> wrote in message
news:86fzc2icsm.fsf@huldreheim.huldreskog.no...
> Ronald E Jeffries <ronjeffries@acm.org> writes:
>
>
> Assuming that is true for the original code-lines, what guarantee do
> you have that it is still true after refactoring the code? How can you
> show that your refactoring is correct, and didn't leave any dead code
> around or that there are still no untested pathways through your code?
I suppose refactoring means refactoring everything, including unit tests
needed. Tests should be meant as a part of the code itself.
If some tests were designed with functional perspective in mind as, for
example, the test that verifies the results of sorting operation it may
still be valid after refactoring because it was designed to check function
which didn't change.
Pure structured tests will required changes: some may be no more valid and
will be replaced; some may need modifications.
----
Best Wishes,
Vladimir
| |
| Leif Roar Moldskred 2004-03-26, 11:50 pm |
| "Vladimir Trushkin" <NspamOtrushkin@tut.by> writes:
> "Leif Roar Moldskred" <rmoldskr+usenet@online.no> wrote in message
> I suppose refactoring means refactoring everything, including unit tests
> needed. Tests should be meant as a part of the code itself.
If you rewrite both the functional code and the tests, you destroy the
integrity of the test cases.
> If some tests were designed with functional perspective in mind as, for
> example, the test that verifies the results of sorting operation it may
> still be valid after refactoring because it was designed to check function
> which didn't change.
While the test should still be functionally valid after a refactoring,
there's no guarantee that it still provides proper coverage of the
code. (Assuming they did so before.)
> Pure structured tests will required changes: some may be no more valid and
> will be replaced; some may need modifications.
So, basically, to be able to have proper code coverage with TDD, you
have to manually assure that your test-cases provide proper code
coverage?
--
Leif Roar Moldskred
| |
| David Lightstone 2004-03-26, 11:50 pm |
|
"Ronald E Jeffries" <ronjeffries@acm.org> wrote in message
news:pd1r50p6j6ikojp2500aantdg8meirsqur@
4ax.com...
> On Sun, 21 Mar 2004 13:24:12 +0200, "Vladimir Trushkin"
> <NspamOtrushkin@tut.by> wrote:
>
far.[color=darkred]
This[color=darkred]
>
> If every single line of code was written only if it was necessary to
> make a test pass, what would be the resulting coverage, statement,
> branch, and any other of interest?
Please treat the above question as a troll, or a diversion
The question has been addressed before, there are members of the Agile
Alliance (known to Ron), well able to give Ron an answer that he can not
choose to ignore
>
> --
> Ron Jeffries
> www.XProgramming.com
> I'm giving the best advice I have. You get to decide if it's true for you.
| |
| David Lightstone 2004-03-26, 11:50 pm |
|
"John Roth" <newsgroups@jhrothjr.com> wrote in message
news:105r370isff9kb5@news.supernews.com...
>
> "David Lightstone" <david._NoSpamlightstone@prodigy.net> wrote in message
> news:jLd7c.37738$xA5.841@newssvr16.news.prodigy.com...
> message
> in
blessing[color=darkred]
"and[color=darkred]
>
> No.
Was the an effort to publish them in a reputable journal? or shall we treat
the claim as folklore?
97.5%?[color=darkred]
>
> I've run across such managers. Since the Agile
> Invariant is that there will be a production quality
> deployable at the end of every iteration, the answer
> at the end of the iteration is: 100% by definition.
Wish I had your dictionary. You seem to be using a form of reasoning called
be some - circular. By definition there is production quality at the end of
every iteration, ergo 100% tested at every iteration. Or is it 100% tested
at every iteration ergo production quality. Yet you claim above 90%
statement coverage. John, I think one of use has gotten . Any
reasonable chance that I am misquoting you or perhaps quoting you out of
context. Please explain? Obviously the metric doesn't include coverage. Yet
you wish to imply coverage.
>
> If you aren't doing that, you aren't doing Agile
> regardless of what you say you are doing.
>
> the
>
> I'm well aware of them. That does indeed apply to
> the requirements, which is why all agile methodologies
> I'm aware of sort the requirements by order of decreasing
> business value, and cut the development process off
> when you hit the law of diminishing returns.
And for some reason it does not apply to design, implementation or testing?
>
> This does, of course, depend on using a short
> cycle incremental development system.
>
> has
> project
>
> Since it's gotten to as a byproduct of doing something
> else which is valuable in its own right, I'd have to
> agree with the first two sentences.
>
> I would, however, disagree strongly with the third
> sentence: if there is a requirement for any particular
> metric to meet a specific goal, it's best done as an
> ongoing part of the project, not to wait until it's done.
>
> Note that this ties in with the answer to the previous
> paragraph: at the end of the iteration, the result is a
> production quality deployable. If you require that the
> code satisfy some particular metric, that's part of the
> definition of "production quality" for that project.
With so many possible metrics, it should be real easy to select one that
yields erroneous code.
and when it is all integrated (ie the final iteration), which global metric
is applicable, (let me guess the number of bugs caught by the acceptance
test)
>
your[color=darkred]
I[color=darkred]
>
> Only from people who are fanatically opposed to
> the possibility of it being true. The rest of the
> people will check it out for themselves. Note the
> emphasis on the word "fanatic", which goes to the
> basis of the person's belief system. I've frequently
> observed that this seems to be tied into either their
> financial or professional status.
If you find anything erroneous in the statements that I have made please do
correct me. As for your inuendo, I shall ignore that, treating it as an
effort to erroneously imply that I have been and am misinformed
>
> John Roth
>
>
| |
| John Roth 2004-03-26, 11:50 pm |
| David, do you really expect me to believe that
you know so little about XP that you don't
realize that your questions are arrant nonsense?
We've been around this block before. Let me
repeat once more: XP does not have phases.
With two exceptions, *everything* is done
within a fixed length iteration. Everything includes
all work from detailed requirements through final
packaging for deployment. The exceptions are the
initial requirements work, and the actual deployment.
"David Lightstone" <david._NoSpamlightstone@prodigy.net> wrote in message
news:ezj7c.62115$ye4.8383@newssvr33.news.prodigy.com...
>
> "John Roth" <newsgroups@jhrothjr.com> wrote in message
> news:105r370isff9kb5@news.supernews.com...
message[color=darkred]
in[color=darkred]
wrote[color=darkred]
> blessing
> "and
>
> Was the an effort to publish them in a reputable journal? or shall we
treat
> the claim as folklore?
Do whatever you want. You will anyway. If you
want any credibility other than with the people you
posture before, you could check some out
yourself. It's not all that hard, after all.
the[color=darkred]
> 97.5%?
>
> Wish I had your dictionary. You seem to be using a form of reasoning
called
> be some - circular. By definition there is production quality at the end
of
> every iteration, ergo 100% tested at every iteration. Or is it 100% tested
> at every iteration ergo production quality. Yet you claim above 90%
> statement coverage. John, I think one of use has gotten . Any
> reasonable chance that I am misquoting you or perhaps quoting you out of
> context. Please explain? Obviously the metric doesn't include coverage.
Yet
> you wish to imply coverage.
The process calls for the product status at the end of the
iteration to be "production quality deployable." It's up
to the various people concerned to make this happen.
If it doesn't happen occasionally, well, stuff happens.
If it doesn't happen consistently, then there's a process
problem that needs to be fixed. So while it's a reasonable
question to ask how much of the testing is done at the
end of the iteration, the expected answer is: 100%.
If it isn't, something needs to be done to make it happen
that way.
Consequently, there is no subsequent testing effort.
I hope this is clear enough for you.
of[color=darkred]
and[color=darkred]
>
> And for some reason it does not apply to design, implementation or
testing?
As I said above, everything is done in the same
iteration. There are no separate design or
testing "phases." The entire notion is such utter
nonsense to anyone who actually has made an
effort to understand XP that it is difficult to see
how anyone can still be uttering it after this
length of time.
work[color=darkred]
the[color=darkred]
>
> With so many possible metrics, it should be real easy to select one that
> yields erroneous code.
>
>
> and when it is all integrated (ie the final iteration), which global
metric
> is applicable, (let me guess the number of bugs caught by the acceptance
> test)
Since the acceptance tests are written as part of the
iteration, before the developers write the code, it's
hard to see how there could be bugs - the developers
simply code to make them pass.
> your
belief,[color=darkred]
> I
>
>
> If you find anything erroneous in the statements that I have made please
do
> correct me. As for your inuendo, I shall ignore that, treating it as an
> effort to erroneously imply that I have been and am misinformed
As I've shown throughout, you're demonstrating so
little understanding of the XP process that everything
you say is basically misinformed.
I'm a firm believer in the saying: "never ascribe to
malice what can be ascribed to stupidity."
John Roth
| |
| John Roth 2004-03-26, 11:50 pm |
|
"Vladimir Trushkin" <NspamOtrushkin@tut.by> wrote in message
news:c3ju1b$dhc$1@news.gngidc.net...
> "John Roth" <newsgroups@jhrothjr.com> wrote in message
> news:105n7rian8a71cd@news.supernews.com...
message[color=darkred]
>
>
> We were said that it was _approximately_ 100% of Statement coverage so
far.
> So, I can't believe this may do as much as 90s of Condition coverage. This
> only could happen if your code straight with almost no logical branching.
>
> Can you give us the source of this information?
Reported measurements by working XP teams.
John Roth
>
> ----
> Best Wishes,
> Vladimir
>
>
| |
| John Roth 2004-03-26, 11:50 pm |
| "Leif Roar Moldskred" <rmoldskr+usenet@online.no> wrote in message
news:86fzc2icsm.fsf@huldreheim.huldreskog.no...
> Ronald E Jeffries <ronjeffries@acm.org> writes:
>
>
> Assuming that is true for the original code-lines, what guarantee do
> you have that it is still true after refactoring the code? How can you
> show that your refactoring is correct, and didn't leave any dead code
> around or that there are still no untested pathways through your code?
Thank you! This is the best question yet on this thread.
The answer is that you can't, and it's a real question that's
being asked within the XP community.
At this point, I'm not aware of any studies that have addressed
this point. I've heard of some teams that run coverage analyzers
every couple of w s, but I don't know whether they're doing
it to assure themselves that the coverage numbers suddenly don't
drop, or whether they find it necessary to add tests to bring
the coverage numbers back up to where they should be.
I'd certainly like to know the answer to this one myself.
There are a couple of considerations though. One is that XP
is focused on end results: that is, whether the number of
field reported defects is within the customer's quality goals.
As I alluded to earlier, other measurements of code quality
are secondary to that goal. Unfortunately, that piece of
feedback has the second longest time lag in the process.
The other is that the TDD process basically assumes that
the rest of the code is clean. If it isn't, your tests blow up
and you wind up having to debug. Until you've practiced
TDD, you don't realize what an extreme statement that is:
I've heard any number of developers say that what they
like best about TDD is that they're forgetting how to use
the debugger.
So if code quality starts declining, that's going to be
very noticable very quickly.
Hope this answered the question.
John Roth
>
> --
> Leif Roar Moldskred
| |
| Nick Landsberg 2004-03-26, 11:50 pm |
| John Roth wrote:
> "Vladimir Trushkin" <NspamOtrushkin@tut.by> wrote in message
> news:c3ju1b$dhc$1@news.gngidc.net...
>
[SNIP]
>
>
>
> Reported measurements by working XP teams.
>
> John Roth
>
>
Where are they published? A URL would be helpfull.
A paper in some journal would be more helpfull.
--
"It is impossible to make anything foolproof
because fools are so ingenious"
- A. Bloch
| |
| John Roth 2004-03-26, 11:50 pm |
|
"Nick Landsberg" <hukolau@NOSPAM.att.net> wrote in message
news:dPk7c.2775$tY6.77622@bgtnsc04-news.ops.worldnet.att.net...
> John Roth wrote:
>
>
>
> [SNIP]
>
This[color=darkred]
branching.[color=darkred]
The theory behind the branch coverage starts out with
straight line code. That's one test. Then the next test
adds the condition. If the tests keep passing, you've
gotten both legs.
I suspect that the reason why branch coverage comes
in lower than statement coverage is simply that it's very
difficult to maintain the discipline of adding exactly the
code required for the test, and not one keystroke more.
To continue on with this thought, I don't know of any
path coverage measurements. I'd expect them to come
in lower than branch coverage for the obvious reasons,
but I wouldn't expect them to come in that much lower.
The reason is that the pervasive testing forces low
coupling and short methods. In things I've written, I'd
guess that less than half of the substantive (that is, excluding
getters and setters) methods have any kind of conditional logic.
[color=darkred]
>
> Where are they published? A URL would be helpfull.
> A paper in some journal would be more helpfull.
I don't know where you can find some of this stuff.
Right now the Yahoo mailing lists are where the cutting
edge is being worked on, and sometimes it winds up on
one of the dozen or so web sites that are more or less
central to XP, and sometimes it doesn't.
That's not, rather obviously, a good situation, since what
you might call "Advances in XP" aren't being publicized in
any kind of a coherent fashion. There are, for example, a
number of shops certified at CMM level 3, and there are
a number of shops that have worked out a minimally
intrusive, lightweight requirements tracability process.
I don't know where any of this is written up where it's
accessable.
John Roth
>
> --
> "It is impossible to make anything foolproof
> because fools are so ingenious"
> - A. Bloch
| |
| Ronald E Jeffries 2004-03-26, 11:50 pm |
| On Sun, 21 Mar 2004 12:27:35 -0500, "John Roth"
<newsgroups@jhrothjr.com> wrote:
>David, do you really expect me to believe that
>you know so little about XP that you don't
>realize that your questions are arrant nonsense?
Do da name "Troll" strike a familiar note?
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
| |
| Ronald E Jeffries 2004-03-26, 11:50 pm |
| On 21 Mar 2004 13:51:05 +0100, Leif Roar Moldskred
<rmoldskr+usenet@online.no> wrote:
>
>Assuming that is true for the original code-lines, what guarantee do
>you have that it is still true after refactoring the code? How can you
>show that your refactoring is correct, and didn't leave any dead code
>around or that there are still no untested pathways through your code?
Unresponsive to the original question. But there is no guarantee. If
the code is dead, then I'd think it doesn't matter much. If it's
untested, I'd certainly be more concerned.
When refactoring with an automated tool, of course, we are protected
by the fact (?) that the tool works, and errors are far less likely.
When refactoring even manually, the tests seem always to be quite
comprehensive enough to protect us, showing up things that go wrong.
Recall also that XP teams have a second line of defense, their
Customer Acceptance Tests, which also flag when things go wrong. The
result is that people using these practices build up confidence in how
well things are going,
But I'm not clear on where you're going with your line of thought. Our
purpose in XP is not to have high code coverage. It is to have a set
of practices which work together to allow us to deliver a stream of
features, beginning from a simple system, and to take it forward to a
full system, without danger of wedging, or excessive rewriting.
A lot of very experienced very successful software people have been
working this way for quite a few years now, and we're having good
results. We're reporting those results and love to try to explain what
we do, why it seems to work, and so on.
So ... where are you going with your questions?
Regards,
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
| |
| Jason Nocks 2004-03-26, 11:50 pm |
| Leif Roar Moldskred wrote:
> Ronald E Jeffries <ronjeffries@acm.org> writes:
>
>
>
>
> Assuming that is true for the original code-lines, what guarantee do
> you have that it is still true after refactoring the code? How can you
> show that your refactoring is correct, and didn't leave any dead code
> around or that there are still no untested pathways through your code?
>
I refer you to the first paragraph or so on http://www.refactoring.com/
----
What is Refactoring?
Refactoring is a disciplined technique for restructuring an existing
body of code, altering its internal structure without changing its
external behavior. Its heart is a series of small behavior preserving
transformations. Each transformation (called a 'refactoring') does
little, but a sequence of transformations can produce a significant
restructuring. Since each refactoring is small, it's less likely to go
wrong. The system is also kept fully working after each small
refactoring, reducing the chances that a system can get seriously broken
during the restructuring.
----
Note: the important part here is that each change/transformation is
behavior preserving, i.e, if you change the behavior of the code, then
you are not refactoring. I have heard developers I've worked with (who
were not claiming they were practicing XP), call any change to code
"refactoring". Maybe you don't feel this way, but I thought I'd try to
clear this up.
To me, adding new pathways through the code indicates adding new
behavior. This is not refactoring. Refactoring is typically about
removing dead or duplicate pathways through the code, making the number
of pathways smaller not larger. For example, if you have code that is
slightly different but performing the same task, you make a series of
small changes to make the code similar enough until you actually delete
one of the implementations. The steps must be very small to ensure that
you don't actually cause a change in behavior.
The assurance that this behavior is preserved comes from writing tests
to check the behavior of the code before writing the code. If you change
the behavior, and the tests were written to check the behavior, some of
the tests will break. This does require people to understand and follow
the practices correctly. This is one of the reasons why many XP
practioners refer to XP as being "highly disciplined".
Cheers,
Jason Nocks
SourceXtreme, Inc.
http://www.sourcextreme.com/
| |
| Jason Nocks 2004-03-26, 11:50 pm |
| David Lightstone wrote:
> "Ronald E Jeffries" <ronjeffries@acm.org> wrote in message
> news:pd1r50p6j6ikojp2500aantdg8meirsqur@
4ax.com...
>
>
> far.
>
>
> This
>
>
> Please treat the above question as a troll, or a diversion
Why?
> The question has been addressed before, there are members of the Agile
> Alliance (known to Ron), well able to give Ron an answer that he can not
> choose to ignore
Do you care to share this response with the rest of us? Or at least some
rough approximation?
I thought Ron's post was directly related to the thread of discussion. I
had an extremely similar response in mind (IMHO).
The response I had in mind was going to be something like:
If I follow TDD, I never add functionality until I have a failing test
that requires that functionality. Doing this, I would expect to have
tests that check for 100% of the functionality I create. Is there any
reason to believe otherwise?
For pratical reasons, I probably won't write tests that check the
simplest accessors and mutators (Simple property Get/Set methods). If I
don't add these accessors and mutators until I have a failing test,
however, I should still expect extremely high metrics.
I still prefer Ron's response, however, because it mostly covers
everything I wanted to say in fewer lines of text.
Cheers,
Jason Nocks
SourceXtreme, Inc.
http://www.sourcextreme.com/
| |
| Robert C. Martin 2004-03-26, 11:50 pm |
| On 21 Mar 2004 16:53:35 +0100, Leif Roar Moldskred
<rmoldskr+usenet@online.no> wrote:
>"Vladimir Trushkin" <NspamOtrushkin@tut.by> writes:
>
>
>
>If you rewrite both the functional code and the tests, you destroy the
>integrity of the test cases.
No, you don't. You have the production code to keep the tests in
shape, and the tests to keep the production code in shape. All that
is required is a bit of care.
>
>While the test should still be functionally valid after a refactoring,
>there's no guarantee that it still provides proper coverage of the
>code. (Assuming they did so before.)
Firstly, line coverage is not the goal of TDD; though we often get
very good marks. Secondly since all required behaviors are intact,
there is good reason to believe that coverage has not been
significantly eroded. Thirdly, a little care is required.
>
>So, basically, to be able to have proper code coverage with TDD, you
>have to manually assure that your test-cases provide proper code
>coverage?
If code coverage is your aim, you should use a code coverage tool.
| |
| Jason Nocks 2004-03-26, 11:50 pm |
| Ronald E Jeffries wrote:
> On 21 Mar 2004 13:51:05 +0100, Leif Roar Moldskred
> <rmoldskr+usenet@online.no> wrote:
>
>
>
>
> Unresponsive to the original question. But there is no guarantee. If
> the code is dead, then I'd think it doesn't matter much. If it's
> untested, I'd certainly be more concerned.
>
> When refactoring with an automated tool, of course, we are protected
> by the fact (?) that the tool works, and errors are far less likely.
>
> When refactoring even manually, the tests seem always to be quite
> comprehensive enough to protect us, showing up things that go wrong.
> Recall also that XP teams have a second line of defense, their
> Customer Acceptance Tests, which also flag when things go wrong. The
> result is that people using these practices build up confidence in how
> well things are going,
Plus, a pair programmer as yet another line of defense :)
>
> But I'm not clear on where you're going with your line of thought. Our
> purpose in XP is not to have high code coverage. It is to have a set
> of practices which work together to allow us to deliver a stream of
> features, beginning from a simple system, and to take it forward to a
> full system, without danger of wedging, or excessive rewriting.
>
> A lot of very experienced very successful software people have been
> working this way for quite a few years now, and we're having good
> results. We're reporting those results and love to try to explain what
> we do, why it seems to work, and so on.
>
> So ... where are you going with your questions?
>
> Regards,
>
Cheers,
Jason Nocks
SourceXtreme, Inc.
http://www.sourcextreme.com/
| |
| David Lightstone 2004-03-26, 11:50 pm |
|
"John Roth" <newsgroups@jhrothjr.com> wrote in message
news:105rk6im0h6vd05@news.supernews.com...
> David, do you really expect me to believe that
> you know so little about XP that you don't
> realize that your questions are arrant nonsense?
I realize the purpose of my questions. Their completeness as well as their
incompleteness.
>
> We've been around this block before. Let me
> repeat once more: XP does not have phases.
> With two exceptions, *everything* is done
> within a fixed length iteration. Everything includes
> all work from detailed requirements through final
> packaging for deployment. The exceptions are the
> initial requirements work, and the actual deployment.
I am well aware that XP is done in increments. I am also well aware that the
unit test cases only cover the things that the analysts consider as worthy
of test or for which there has been a post delivery field observed failure
condition. (because the next iteration/revision must show evidence of
"solving" the problem
The existance of well know failure conditions observed in the field implies
that path or statement coverage has been less than complete. When you state
100% tested implies production quality (or is it the other way around) you
are exagarating somewhat. (see expected answer below)
<snip>
> called
> of
tested[color=darkred]
> Yet
>
> The process calls for the product status at the end of the
> iteration to be "production quality deployable." It's up
> to the various people concerned to make this happen.
>
> If it doesn't happen occasionally, well, stuff happens.
> If it doesn't happen consistently, then there's a process
> problem that needs to be fixed. So while it's a reasonable
> question to ask how much of the testing is done at the
> end of the iteration, the expected answer is: 100%.
> If it isn't, something needs to be done to make it happen
> that way.
Expected answer. Nice hedge. You have to dig to find the hedge.
So let me see if I understand this - expected 100% tested implies production
quality, or is it the other way around
Then as I indicate earlier - it is 100% of the developed tests, rather than
100% statement coverage or path coverage.
>
> Consequently, there is no subsequent testing effort.
>
> I hope this is clear enough for you.
>
> of
> and
> testing?
>
> As I said above, everything is done in the same
> iteration. There are no separate design or
> testing "phases." The entire notion is such utter
> nonsense to anyone who actually has made an
> effort to understand XP that it is difficult to see
> how anyone can still be uttering it after this
> length of time.
You erroneously assume that I am thinking in terms of waterfall. I am not.
>
> work
> the
> metric
>
> Since the acceptance tests are written as part of the
> iteration, before the developers write the code, it's
> hard to see how there could be bugs - the developers
> simply code to make them pass.
Yes, I am well aware of the game. Require the customer to have done a
diligent analysis before the coding begins. One might foolishly conclude
that the waterfall model has been reworked a bit. Analyze, design acceptance
test, implement acceptance test, test acceptance, give coders their
requirements, code, test.
>
of[color=darkred]
> belief,
> do
>
> As I've shown throughout, you're demonstrating so
> little understanding of the XP process that everything
> you say is basically misinformed.
>
> I'm a firm believer in the saying: "never ascribe to
> malice what can be ascribed to stupidity."
>
Believe as you wish
> John Roth
>
>
| |
| David Lightstone 2004-03-26, 11:50 pm |
|
"Jason Nocks" <nocksj@sourcextreme.com> wrote in message
news:1c208$405e1622$cff54506$19407@dcane
t.allthenewsgroups.com...
> David Lightstone wrote:
>
branching.[color=darkred]
>
> Why?
>
>
> Do you care to share this response with the rest of us? Or at least some
> rough approximation?
>
> I thought Ron's post was directly related to the thread of discussion. I
> had an extremely similar response in mind (IMHO).
>
> The response I had in mind was going to be something like:
>
> If I follow TDD, I never add functionality until I have a failing test
> that requires that functionality. Doing this, I would expect to have
> tests that check for 100% of the functionality I create. Is there any
> reason to believe otherwise?
What one expects to happen - that is the assumption being made isn't it?
Accept it as valid if you wish. Is there any reason to believe it is so?
Gotta watch those assumptions, yours are not mine. Helps to point them out
when you see them sometimes. There is this tendency to avoid identifying
assumptions and simply assume them to be true
>
> For pratical reasons, I probably won't write tests that check the
> simplest accessors and mutators (Simple property Get/Set methods). If I
> don't add these accessors and mutators until I have a failing test,
> however, I should still expect extremely high metrics.
>
> I still prefer Ron's response, however, because it mostly covers
> everything I wanted to say in fewer lines of text.
>
> Cheers,
> Jason Nocks
> SourceXtreme, Inc.
> http://www.sourcextreme.com/
>
| |
| Robert C. Martin 2004-03-26, 11:50 pm |
| Just for fun I downloaded Clover and ran a rough coverage analysis
over FitNesse (http://fitnesse.org). It reports over 80% line
coverage, 80% method coverage, and 60% conditional coverage -- just
when I run the unit tests.
Much of the undercoverage can be accounted for by the fact that
FitNesse runs much of its code in a completely different JVM from
which the Clover instrumentation does not work. I could probably fix
this if I got motivated enough.
| |
| Jason Nocks 2004-03-26, 11:50 pm |
| David Lightstone wrote:
> "Jason Nocks" <nocksj@sourcextreme.com> wrote in message
> news:1c208$405e1622$cff54506$19407@dcane
t.allthenewsgroups.com...
>
>
> What one expects to happen - that is the assumption being made isn't it?
Let me try to make it even clearer:
For every behavior, prior to creating that behavior, tests for those
behaviors will be written. So, the number of tests is *defined* as equal
to the number of behaviors.
This is not an assumption. It's what the definition of Test First means
in XP, TDD in particular.
It's easy to do a quick calculation. It's simply test coverage =
behaviors tested / total behaviors = 100%.
This is a tiny bit of an oversimplification (as I mentioned later in the
post - particularly with respect to the simplest functions such as basic
get/set accessors/mutators), but it does not require advanced thought to
get the basic idea. If you get in the practice of writing tests for
every behavior before you implement that behavior, you will end up with
tests that cover approximately 100% of the behaviors.
Further, if one desires to question this fairly simple logic, one can
run a quick metric. I believe that others have posted or discussed these
metrics.
When I see the project ship on time and *under* budget, I don't tend to
feel compelled to wonder about these straightforward reasonings and do
exhaustive metrics checking. We were quite pleased with the metrics we
did measure (velocity, budget, etc.).
On some of the bigger XP projects, there are trackers, etc. for these
sorts of things. I believe the usual approach, however, is to
demonstrate by shipping working, tested software, as we did on my last
project.
> Accept it as valid if you wish. Is there any reason to believe it is so?
See above.
> Gotta watch those assumptions, yours are not mine. Helps to point them out
Never said they were. In fact it was prefixed with "If I follow TDD", so
that was *my* assumption, and it was clearly stated.
> when you see them sometimes. There is this tendency to avoid identifying
> assumptions and simply assume them to be true
No, I was doing my best to identify *my* assumptions.
And you still didn't answer the question.
Is there some evidence or reason to suggest that this fairly
straightforward logic is *not* expected to hold true?
[color=darkred]
>
Cheers,
Jason Nocks
SourceXtreme, Inc.
http://www.sourcextreme.com/
| |
| Vladimir Trushkin 2004-03-26, 11:50 pm |
|
"Leif Roar Moldskred" <rmoldskr+usenet@online.no> wrote in message
news:86brmqi4cg.fsf@huldreheim.huldreskog.no...
> "Vladimir Trushkin" <NspamOtrushkin@tut.by> writes:
>
>
> So, basically, to be able to have proper code coverage with TDD, you
> have to manually assure that your test-cases provide proper code
> coverage?
I am not quite sure I understood the question. Still I'll try to
answer/comment it.
I would do coverage analysis not manually, but rather in an automated way. I
don't know if this is practical to do it manually.
Anyway, you should do it _after_ the code was written, so this is by no
means a TDD.
----
Best Wishes,
Vladimir
| |
| David Lightstone 2004-03-26, 11:50 pm |
|
"Jason Nocks" <nocksj@sourcextreme.com> wrote in message
news:5dee0$405e6a71$cff54506$25748@dcane
t.allthenewsgroups.com...
> David Lightstone wrote:
>
>
> Let me try to make it even clearer:
> For every behavior, prior to creating that behavior, tests for those
> behaviors will be written. So, the number of tests is *defined* as equal
> to the number of behaviors.
All you are doing is pushing your assumptions around. In this case you have
assumed that this relationship will be adequate to achieve coverage. (which
to me means path)
"Just for fun I downloaded Clover and ran a rough coverage analysis
over FitNesse (http://fitnesse.org). It reports over 80% line
coverage, 80% method coverage, and 60% conditional coverage -- just
when I run the unit tests." The author of the quote is Bob Martin. Posted
today or yesterday
There is an explination contained within that post for the discrepancy, but
I doubt if the high 90's claimed by John Roth will be achieved
The "experiment" indicates a dubious assumption. From your perspective,
probably that the the number of paths created in the code equals the number
of behaviors.
>
> This is not an assumption. It's what the definition of Test First means
> in XP, TDD in particular.
Somehow I think that you can't define reality to suit your pleasure. The
definition is not consistent with "experiment" see above. In this case the
definition, is difficult to apply. Reality being what it is, I'd say good
theory, bad result. The only question is whether it is reasonable likely
that good results can be consistently obtained.
>
> It's easy to do a quick calculation. It's simply test coverage =
> behaviors tested / total behaviors = 100%.
>
> This is a tiny bit of an oversimplification (as I mentioned later in the
> post - particularly with respect to the simplest functions such as basic
> get/set accessors/mutators), but it does not require advanced thought to
> get the basic idea. If you get in the practice of writing tests for
> every behavior before you implement that behavior, you will end up with
> tests that cover approximately 100% of the behaviors.
>
> Further, if one desires to question this fairly simple logic, one can
> run a quick metric. I believe that others have posted or discussed these
> metrics.
>
> When I see the project ship on time and *under* budget, I don't tend to
> feel compelled to wonder about these straightforward reasonings and do
> exhaustive metrics checking. We were quite pleased with the metrics we
> did measure (velocity, budget, etc.).
>
> On some of the bigger XP projects, there are trackers, etc. for these
> sorts of things. I believe the usual approach, however, is to
> demonstrate by shipping working, tested software, as we did on my last
> project.
>
>
> See above.
>
out[color=darkred]
>
> Never said they were. In fact it was prefixed with "If I follow TDD", so
> that was *my* assumption, and it was clearly stated.
>
>
> No, I was doing my best to identify *my* assumptions.
>
> And you still didn't answer the question.
>
> Is there some evidence or reason to suggest that this fairly
> straightforward logic is *not* expected to hold true?
See above
>
>
> Cheers,
> Jason Nocks
> SourceXtreme, Inc.
> http://www.sourcextreme.com/
| |
| David Lightstone 2004-03-26, 11:50 pm |
|
"John Roth" <newsgroups@jhrothjr.com> wrote in message
news:105rnq5qde8i2bf@news.supernews.com...
>
> "Nick Landsberg" <hukolau@NOSPAM.att.net> wrote in message
> news:dPk7c.2775$tY6.77622@bgtnsc04-news.ops.worldnet.att.net...
> This
> branching.
>
> The theory behind the branch coverage starts out with
> straight line code. That's one test. Then the next test
> adds the condition. If the tests keep passing, you've
> gotten both legs.
>
> I suspect that the reason why branch coverage comes
> in lower than statement coverage is simply that it's very
> difficult to maintain the discipline of adding exactly the
> code required for the test, and not one keystroke more.
This difficulty is not a rare phenomena (as measured the path coverage). It
corresponds to between 5% and 10% of the code base (corresponding to your
low 90's path coverage estimate)
I can only wonder whether it will be easy or difficult to locate this
untested code.
This beings us back to - locating the final 10% of the bugs consumes x% of
the budget.
>
> To continue on with this thought, I don't know of any
> path coverage measurements. I'd expect them to come
> in lower than branch coverage for the obvious reasons,
> but I wouldn't expect them to come in that much lower.
> The reason is that the pervasive testing forces low
> coupling and short methods. In things I've written, I'd
> guess that less than half of the substantive (that is, excluding
> getters and setters) methods have any kind of conditional logic.
>
>
> I don't know where you can find some of this stuff.
> Right now the Yahoo mailing lists are where the cutting
> edge is being worked on, and sometimes it winds up on
> one of the dozen or so web sites that are more or less
> central to XP, and sometimes it doesn't.
>
> That's not, rather obviously, a good situation, since what
> you might call "Advances in XP" aren't being publicized in
> any kind of a coherent fashion. There are, for example, a
> number of shops certified at CMM level 3, and there are
> a number of shops that have worked out a minimally
> intrusive, lightweight requirements tracability process.
> I don't know where any of this is written up where it's
> accessable.
>
> John Roth
>
>
| |
| Vladimir Trushkin 2004-03-26, 11:50 pm |
| "Jason Nocks" <nocksj@sourcextreme.com> wrote in message
news:e1a6c$405e12ac$cff54506$18795@dcane
t.allthenewsgroups.com...
> ----
> What is Refactoring?
>
> Refactoring is a disciplined technique for restructuring an existing
> body of code, altering its internal structure without changing its
> external behavior. Its heart is a series of small behavior preserving
> transformations. Each transformation (called a 'refactoring') does
> little, but a sequence of transformations can produce a significant
> restructuring. Since each refactoring is small, it's less likely to go
> wrong. The system is also kept fully working after each small
> refactoring, reducing the chances that a system can get seriously broken
> during the restructuring.
I found it quite interesting that only small changes are called refactoring.
I heard someone referred to completely rewriting a portion of a code as
being a refactoring.
----
Best Wishes,
Vladimir
| |
| Vladimir Trushkin 2004-03-26, 11:50 pm |
| "Robert C. Martin" <unclebob@objectmentor.com> wrote in message
news:5rps50trp1vc1cfe5gtpaq0b582bkn7up8@
4ax.com...
> Just for fun I downloaded Clover and ran a rough coverage analysis
> over FitNesse (http://fitnesse.org). It reports over 80% line
> coverage, 80% method coverage, and 60% conditional coverage -- just
> when I run the unit tests.
Here we go.
60% is damp low. You have left 40% of decisions in your code not examined by
tests. Adding tests to cover those would be a good step toward better
testing quality.
----
Best Wishes,
Vladimir
| |
| Vladimir Trushkin 2004-03-26, 11:50 pm |
|
"Jason Nocks" <nocksj@sourcextreme.com> wrote in message
news:1c208$405e1622$cff54506$19407@dcane
t.allthenewsgroups.com...
> David Lightstone wrote:
>
[color=darkred]
> If I follow TDD, I never add functionality until I have a failing test
> that requires that functionality. Doing this, I would expect to have
> tests that check for 100% of the functionality I create. Is there any
> reason to believe otherwise?
Testing Functionality is a Behavioral testing, when we are mostly talking
about Structured testing if it comes to coverage analysis.
TDD tests are preferably functional (behavioral). This is very useful for
supporting easy changes in code. Once you have changed something you can
easily check if everything still works fine. Thus serving regression testing
purposes. From this viewpoint TDD is a testing, despite of some people here
try to convince us this is not.
Still some purely design decisions may be introduced into the code, not
visible from functional perspective, thus the need for testing them may not
be recognized. As previous posts show not all of design paths are being
covered by test designed keeping the functional perspective in mind. Even
statement coverage is only as high as _approximately_ 100%, condition
coverage drops below 60%.
----
Best Wishes,
Vladimir
| |
| Vladimir Trushkin 2004-03-26, 11:50 pm |
| Jason Nocks" <nocksj@sourcextreme.com> wrote in message
news:5dee0$405e6a71$cff54506$25748@dcane
t.allthenewsgroups.com...[color=darkred]
> David Lightstone wrote:
>
[color=darkred]
Numbers are more convincing though.
The numbers Robert has given are rather extreme than high.
----
Best Wishes,
Vladimir
Some testing is better than no testing, but just slightly.
| |
| Jason Nocks 2004-03-26, 11:50 pm |
| Vladimir Trushkin wrote:
> "Jason Nocks" <nocksj@sourcextreme.com> wrote in message
> news:e1a6c$405e12ac$cff54506$18795@dcane
t.allthenewsgroups.com...
>
>
>
>
> I found it quite interesting that only small changes are called refactoring.
> I heard someone referred to completely rewriting a portion of a code as
> being a refactoring.
That's *exactly* why I posted this :) I'm very glad that you found it
interesting.
This is a common misconception and misuse of the word. This usage is
incorrect. Rewriting code should always be called *rewriting* not
*refactoring*. Think of tiny restructurings when you want to think about
refactoring.
> ----
> Best Wishes,
> Vladimir
Cheers,
Jason Nocks
SourceXtreme, Inc.
http://www.sourcextreme.com/
| |
| Chris Dollin 2004-03-26, 11:50 pm |
| Jason Nocks wrote:
> This is a common misconception and misuse of the word. This usage is
> incorrect. Rewriting code should always be called *rewriting* not
> *refactoring*. Think of tiny restructurings when you want to think about
> refactoring.
Isn't the composition of two refactorings a refactoring?
--
Chris "hence a refactoring can be as big as you please" Dollin
C FAQs at: http://www.faqs.org/faqs/by-newsgro...omp.lang.c.html
C welcome: http://www.angelfire.com/ms3/bchamb...ome_to_clc.html
| |
| thoff 2004-03-26, 11:50 pm |
|
Jason Nocks wrote:
> This is a common misconception and misuse of the word. This usage is
> incorrect. Rewriting code should always be called *rewriting* not
> *refactoring*. Think of tiny restructurings when you want to think about
> refactoring.
In common usage i would say it means something like "changes to
make code better." I don't think there's anything to be
gained by being pendantic about it. If you are making useful
changes it would be very difficult to not introduce new
behaviours or change interfaces. And as your tests would not
be built to detect new behaviours, there is no way for
you to tell if new behaviours have been added. Refactoring
to a class to remove an if statement, for example, from
a testing point-of-view is a dramatic change in behaviour,
but it is something you would do all the time practice.
| |
| Robert C. Martin 2004-03-26, 11:50 pm |
| On Mon, 22 Mar 2004 14:23:56 +0200, "Vladimir Trushkin"
<NspamOtrushkin@tut.by> wrote:
>"Jason Nocks" <nocksj@sourcextreme.com> wrote in message
> news:e1a6c$405e12ac$cff54506$18795@dcane
t.allthenewsgroups.com...
>
>
>I found it quite interesting that only small changes are called refactoring.
>I heard someone referred to completely rewriting a portion of a code as
>being a refactoring.
My particular usage of the words as follows:
Refactoring (N): A single tiny change to the structure of the code
that preserves existing behavior as verified by unit tests.
Refactoring (V): The act of implementing one or more refactorings.
Therefore it is possible to make large changes to the code base and
call the process "refactoring". However the large change must be made
by making a series of very small changes that preserve behavior and
are verified by unit tests.
| |
| Jason Nocks 2004-03-26, 11:50 pm |
| David Lightstone wrote:
> "Jason Nocks" <nocksj@sourcextreme.com> wrote in message
> news:5dee0$405e6a71$cff54506$25748@dcane
t.allthenewsgroups.com...
>
>
> All you are doing is pushing your assumptions around. In this case you have
No, this is what you are *trying* to do. As I stated, this is what TDD
*means*. As in, if you actually followed it, this is what you would
actually be doing. Because this is how TDD is *defined*.
The only assumption is that if someone is discussing TDD, that I have to
assume that they know what TDD means until proven otherwise.
> assumed that this relationship will be adequate to achieve coverage. (which
> to me means path)
>
> "Just for fun I downloaded Clover and ran a rough coverage analysis
> over FitNesse (http://fitnesse.org). It reports over 80% line
> coverage, 80% method coverage, and 60% conditional coverage -- just
> when I run the unit tests." The author of the quote is Bob Martin. Posted
> today or yesterday
>
> There is an explination contained within that post for the discrepancy, but
> I doubt if the high 90's claimed by John Roth will be achieved
>
> The "experiment" indicates a dubious assumption. From your perspective,
> probably that the the number of paths created in the code equals the number
> of behaviors.
Sometimes behavior means path within a method, sometimes it means an
entire method, sometimes it means object, it can mean whatever
particular subset of behavior you wish to focus on. That doesn't change
my statements in any way. For each and every behavior, I strive to write
an automated test that checks that behavior before I implement it.
Nobody here is claiming to conistently actually hit 100% all of the
time. What I here others saying is something like - the nature of the
practice will probably result in very high numbers. To understand this
statement requires that you understand what the practice actually means.
>
> Somehow I think that you can't define reality to suit your pleasure. The
I'm not talking about defining reality, just utilizing a defined
practice to deal with reality.
> definition is not consistent with "experiment" see above. In this case the
> definition, is difficult to apply. Reality being what it is, I'd say good
It is your *opinion* that it's difficult to apply, probably without
having tried the approach questioned. It's simple and easy to say that
something is difficult or unachievable without every seriously trying to
adopt it or understand it.
I, for one, find that my life is easier when I follow TDD then when I
don't. YMMV.
> theory, bad result. The only question is whether it is reasonable likely
> that good results can be consistently obtained.
Well, the people that I know of that consistently practice TDD are more
than happy with the results they consistently obtain and would be more
than happy to share and explain those results. In fact, I believe that
is what Bob Martin's post was all about. Thanks, Bob.
[color=darkred]
<snip>
Cheers,
Jason Nocks
SourceXtreme, Inc.
http://www.sourcextreme.com/
| |
| Robert C. Martin 2004-03-26, 11:50 pm |
| On Mon, 22 Mar 2004 14:29:41 +0200, "Vladimir Trushkin"
<NspamOtrushkin@tut.by> wrote:
>"Robert C. Martin" <unclebob@objectmentor.com> wrote in message
> news:5rps50trp1vc1cfe5gtpaq0b582bkn7up8@
4ax.com...
>
>Here we go.
>
>60% is damp low. You have left 40% of decisions in your code not examined by
>tests.
I came to the same conclusion, though it's important to remember that
there's a large chunk of the code that was throwing exceptions because
clover wasn't accessible from the second JVM. As such, the paths in
that code weren't tracked well.
Still, I Imagine that the 60% ratio is close to what we'll find once
we fix that problem. I looked at a number of the condition issues,
and a large proportion of them turned out to look like this:
public ItalicWidget(ParentWidget parent,
String text) throws Exception
{
super(parent);
Matcher match = pattern.matcher(text);
if(match.find())
addChildWidgets(match.group(1));
else
System.err.println("ItalicWidget: match was not found");
}
This is a design pattern that we used many dozens of times throughout
this particular part of the code. The 'if' statement checks for
something that should be a logical impossibility. So no unit test was
ever written to see if it failed.
Indeed, we've never seen these messages in real life; so we've dodged
this bullet so far. Still, as I looked at it I realized that the
condition is not utterly impossible. One of us could make a
modification to the code that allowed the false branch of that 'if'
statement to execute.
The issue is that there are *two* regular expressions used to match
the text string. The first is applied by the caller of this
constructor. The second is the one you see in the constructor itself.
The two regular expressions are not identical but are supposed to be
"compatible". For example, the two regular expressions for the
ItalicWidget are:
"''.+?''"
"''(.+?)''"
Clearly if a string matches the first, it'll match the second.
Still, if a programmer creates a pair of patterns that aren't quite
compatible, then we could get these errors. On the other hand the
unit tests of the *first* pattern are typically very tight so it's
very unlikely that an incompatibility can exist.
This leave me with the following dilemma.
- Should I write tests for the failing cases?
- Should I eliminate the if statement?
- Should I change the design?
Writing tests for the failing cases doesn't prove anything very
useful. It doesn't prove the two regular expressions are consistent.
It only proves that if they are inconsistent an error will be printed.
In order to write the tests I'll have to replace one of the two
existing expressions, which is tantamount to changing the code.
Eliminating the if statements would increase my Decision coverage, but
would just feel *wrong*. I've seen these "can't happen" messages
printed too often to simply eliminate them.
I don't know how yet, but there may be a way to change the structure
of this code so that the dilemma goes away. Perhaps there is a way to
generate one of the regular expressions from the other. But is this
worth it? What would I really be buying for my effort.
I think this is interesting. Getting these failing branches covered
by tests doesn't feel necessary to my pragmatic self, but feels like
an omission to the part of me that wants things to be tight and
ship-shape. I guess I'll just have to pull out that part of me that
is an engineer and make a decision based upon all the conflicting
variables.
>Adding tests to cover those would be a good step toward better
>testing quality.
| |
| Jason Nocks 2004-03-26, 11:50 pm |
| Vladimir Trushkin wrote:
> "Jason Nocks" <nocksj@sourcextreme.com> wrote in message
> news:1c208$405e1622$cff54506$19407@dcane
t.allthenewsgroups.com...
>
>
>
> Testing Functionality is a Behavioral testing, when we are mostly talking
> about Structured testing if it comes to coverage analysis.
I think I see where you are coming from. If you replace the word
structure with the word object, then the tests in TDD are Unit Tests
that verify the behavior of those objects (the structure in question).
To get any further would be worrying about the internal implementation
details of those objects, which is not what TDD is about. Not sure if
that completely addresses your concern.
I will also add that in TDD refactoring is constantly applied to try to
*simplify* the structure of the code. From your other post, I think that
you're starting to actually *get* what refactoring means.
In TDD, the most common refactorings are removing even small amounts of
duplication. I would suspect that the disparity that you are proposing
would indicate that an XP team were not refactoring sufficiently.
This might be a good metric to check for when a team is not following
the practices correctly. I think that most XP practioners don't measure
everything they could possibly measure. The approach is generally to
measure when you have reason to think that there may be a problem. In
general, an XP team is probably likely to encounter other signs of this
problem much sooner than they would by measuring this metric. But, I
could be *completely* wrong here. Interesting thoughts to ponder...
But I'm starting to "get meta"... As you commented in another post,
numbers are better. Since I've gotten better at XP, I just haven't had a
need to collect thess particular metrics, so I simply haven't.
> TDD tests are preferably functional (behavioral). This is very useful for
> supporting easy changes in code. Once you have changed something you can
> easily check if everything still works fine. Thus serving regression testing
> purposes. From this viewpoint TDD is a testing, despite of some people here
> try to convince us this is not.
Thanks. TDD specifically includes the Unit Testing I was referring to
above (which may address the structural issue you mentioned).
XP also includes working with the user/customer to define Acceptance
Tests. To me, these more closely resemble functional tests in other
approaches.
> Still some purely design decisions may be introduced into the code, not
> visible from functional perspective, thus the need for testing them may not
> be recognized. As previous posts show not all of design paths are being
I think most design changes (typically refactorings in XP) are
recognized sufficiently for my tastes. I generally find out as soon as I
make a design change that breaks the behavior expected of an object in
the application. A Unit Test will fail somewhere almost immediately (In
TDD, the Unit Tests are generally run after every small step within a
refactoring).
If I don't find out from the Unit Tests, I expect to find out from a
failing Acceptance Test shortly thereafter. If I don't have a failing
test, I feel pretty confident that I have not broken anything. This
confidence is one of the things I like best about TDD and XP.
> covered by test designed keeping the functional perspective in mind. Even
> statement coverage is only as high as _approximately_ 100%, condition
> coverage drops below 60%.
>
> ----
> Best Wishes,
> Vladimir
Thanks for the interesting points. I think I see where you are coming
from. I think the differences in perspective tend to result in looking
for different things to measure.
Cheers,
Jason Nocks
SourceXtreme, Inc.
http://www.sourcextreme.com/
| |
| Jason Nocks 2004-03-26, 11:50 pm |
| thoff wrote:
>
> Jason Nocks wrote:
>
>
>
> In common usage i would say it means something like "changes to
> make code better." I don't think there's anything to be
Unfortunately, as I mentioned there is a large *common* misconception
about what refactoring actually means. If we want to let the word equate
the common misuse of the word, then we need a new word to discuss what I
am referring to. I prefer to try to correct this misuse because I think
that the word adequately reflects the intended use.
I referred to a definition from a website purely about refactoring
(refactoring.com). That page indicates that it is maintained by Martin
Fowler. He literally "wrote the book". I have no affiliation with
Thoughtworks or Martin Fowler, his book was simply my first exposure to
the practice.
If you want to disagree with that definition, take it up with him.
> gained by being pendantic about it. If you are making useful
I'm not trying to be pedantic. I'm trying to help people understand what
TDD and XP actually mean. This requires correcting misconceptions about
these practices. It is very difficult to discuss something that the
other person misunderstands without correcting that misconception.
> changes it would be very difficult to not introduce new
> behaviours or change interfaces. And as your tests would not
> be built to detect new behaviours, there is no way for
> you to tell if new behaviours have been added. Refactoring
> to a class to remove an if statement, for example, from
> a testing point-of-view is a dramatic change in behaviour,
As I, and others, have tried to point out, refactoring is not about
*changing* behavior. Refactorings are done with the *intent* of *not*
changing behavior. In my experience, this is commonly misunderstood.
The point I am trying to get across is that if you want to make a change
with the *intent* of changing the behavior of an object or method, then
you are not performing what I call a refactoring. If you are following
TDD, then I believe that you should introduce a new Unit Test before
adding that new behavior.
> but it is something you would do all the time practice.
Cheers,
Jason Nocks
SourceXtreme, Inc.
http://www.sourcextreme.com/
| |
| Ilja Preuß 2004-03-26, 11:50 pm |
| Robert C. Martin wrote:
> My particular usage of the words as follows:
>
> Refactoring (N): A single tiny change to the structure of the code
> that preserves existin | | |