Review of "Developing Java Software"

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Review of "Developing Java Software"

Cédric Beust ♔
I just came across this nice quote from a review made on Slashdot:

"As I alluded to in my opening remarks, this book takes the approach of trying to not only teach Java, but how to approach and actually write programs using Java. The book takes an iterative approach and emphasizes the use of testing tools. Interestingly, they use TestNG rather than the de facto standard JUnit. This is the first book that I've seen that uses TestNG; perhaps JUnit is finally getting some competition? "

This is a review of "Developing Java Software", written mostly by our good buddy Russel Winder.

Thanks Russ!

--
Cédric
--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups "testng-users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/testng-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Review of "Developing Java Software"

Russel Winder
Cédric,

On Wed, 2006-12-13 at 13:27 -0800, Cédric Beust ♔ wrote:
> I just came across this nice quote from a review made on Slashdot:
>
> "As I alluded to in my opening remarks, this book takes the approach
> of trying to not only teach Java, but how to approach and actually
> write programs using Java. The book takes an iterative approach and
> emphasizes the use of testing tools. Interestingly, they use TestNG
> rather than the de facto standard JUnit. This is the first book that
> I've seen that uses TestNG; perhaps JUnit is finally getting some
> competition? "

Some of the comments to the review even actually mention the book :-)

> This is a review of "Developing Java Software", written mostly by our
> good buddy Russel Winder.
>
> Thanks Russ!

No problem.

Some points:

1.  The book is an introduction to programming (in Java) so I doubt
anyone on the TestNG list will ever read it :-)

2.  Because of 1. It is worth repeating something from the preface for
the people on the list:

        Cédric Beust and Alexandru Popescu wrote and continue to develop
        (with others) TestNG -- see http://www.testng.org/.  They were
        always on hand to answer our queries and questions, of which
        there were rather  a lot.  We believe it would be natural
        justice for TestNG to become the new de facto standard test
        framework for Java.

Thanks to you and Alex for doing "the business".  For anyone who doubts
the second sentence, check the mail list archives from last year!

3.  I wonder if TestNG should be in package testng, rather than
org.testng ?

4.  The book uses TestNG 4.7 annotations :-(  We are hoping that this
syntax will be supported until we get the 4th edition out!

--
Russel.
====================================================
Dr Russel Winder                +44 20 7585 2200
41 Buckmaster Road              +44 7770 465 077
London SW11 1EN, UK             [hidden email]

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Review of "Developing Java Software"

Steve Loughran-7

On 14/12/06, Russel Winder <[hidden email]> wrote:

> Some points:
>
> 1.  The book is an introduction to programming (in Java) so I doubt
> anyone on the TestNG list will ever read it :-)

Well I for one am glad that an intro to programming book actually
takes a test centric approach, rather than the
how-to-use-eclipse-to-make-apps books that are full of nothing but
screen shots


> 3.  I wonder if TestNG should be in package testng, rather than
> org.testng ?

-1 to any changes in packaging, as you break things

>
> 4.  The book uses TestNG 4.7 annotations :-(  We are hoping that this
> syntax will be supported until we get the 4th edition out!


welcome to the world of book maintenance.


FWIW, the forthcoming 2nd edition of Java Development with Ant, now
titled, "Ant in Action" is sticking with JUnit 3.8.2 as its test
runner.
This is not through ignorance or the alternatives, but because of the
things that extend it, httpunit and most of all Apache Cactus, the
tool that runs Junit tests inside the app server and reports the
results back over http. These are the tools that enable functional
testing and right now they are hard coded to the junit3.x codebase.

I dont see them moving to JUnit 4 until they've made the one-way jump
to Java5, and of course you cannot easily write code that supports the
3.x and 4.x APIs. Ant 1.7 does, through reflection, but it suffers, as
all reporting is limited to the 3.8.x report format.

So 3.8.x it is, despite all its quirks; At least they are known
deficiencies, and so manageable.

-Steve

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups "testng-users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/testng-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Review of "Developing Java Software"

Cédric Beust ♔
In reply to this post by Russel Winder


On 12/14/06, Russel Winder <[hidden email]> wrote:

1.  The book is an introduction to programming (in Java) so I doubt
anyone on the TestNG list will ever read it :-)

Probably not but thanks to you, newcomers to Java will be exposed to TestNG, which is very good!

2.  Because of 1. It is worth repeating something from the preface for
the people on the list:

        Cédric Beust and Alexandru Popescu wrote and continue to develop
        (with others) TestNG -- see http://www.testng.org/.  They were
        always on hand to answer our queries and questions, of which
        there were rather  a lot.  We believe it would be natural
        justice for TestNG to become the new de facto standard test
        framework for Java.

Thanks to you and Alex for doing "the business".  For anyone who doubts
the second sentence, check the mail list archives from last year!

3.  I wonder if TestNG should be in package testng, rather than
org.testng ?

No, because it would break things, as Steve pointed out, but also because it's non-standard.  Even Sun and JUnit, which were some of the last offenders with incorrect package naming, finally fell in line.

4.  The book uses TestNG 4.7 annotations :-(  We are hoping that this
syntax will be supported until we get the 4th edition out!

Don't worry, support for this syntax will never be removed.

--
Cédric
--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups "testng-users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/testng-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Review of "Developing Java Software"

bklau
In reply to this post by Steve Loughran-7


Steve Loughran wrote:

> On 14/12/06, Russel Winder <[hidden email]> wrote:
>
> > Some points:
> >
> > 1.  The book is an introduction to programming (in Java) so I doubt
> > anyone on the TestNG list will ever read it :-)
>
> Well I for one am glad that an intro to programming book actually
> takes a test centric approach, rather than the
> how-to-use-eclipse-to-make-apps books that are full of nothing but
> screen shots
>
>
> > 3.  I wonder if TestNG should be in package testng, rather than
> > org.testng ?
>
> -1 to any changes in packaging, as you break things
>
> >
> > 4.  The book uses TestNG 4.7 annotations :-(  We are hoping that this
> > syntax will be supported until we get the 4th edition out!
>
>
> welcome to the world of book maintenance.
>
>
> FWIW, the forthcoming 2nd edition of Java Development with Ant, now
> titled, "Ant in Action" is sticking with JUnit 3.8.2 as its test
> runner.

Steve:

Since you are one of the authors of the upcoming book "Ant in Action",
are you giving TestNG some exposure in your book?. A chapter or two?.
Just curious.

-BK-

> This is not through ignorance or the alternatives, but because of the
> things that extend it, httpunit and most of all Apache Cactus, the
> tool that runs Junit tests inside the app server and reports the
> results back over http. These are the tools that enable functional
> testing and right now they are hard coded to the junit3.x codebase.
>
> I dont see them moving to JUnit 4 until they've made the one-way jump
> to Java5, and of course you cannot easily write code that supports the
> 3.x and 4.x APIs. Ant 1.7 does, through reflection, but it suffers, as
> all reporting is limited to the 3.8.x report format.
>
> So 3.8.x it is, despite all its quirks; At least they are known
> deficiencies, and so manageable.
>
> -Steve


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups "testng-users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/testng-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Review of "Developing Java Software"

bklau
In reply to this post by Steve Loughran-7

The "Ant in Action" 's book's content as at Manning site:
Part 1 Learning Ant
1 Introducing Ant
2 A first Ant build
3 Understanding Ant datatypes and properties
4 Testing with JUnit
5 Packaging projects
6 Executing programs
7 Distributing our application
8 Putting it all together
Part 2 Applying Ant
9 Beyond Ant's core tasks
10 Using Ant in large projects
11 Library Management
12 Developing for the web
13 Working with XML
14 Enterprise Java
15 Continuous Integration
16 Deployment

Part 3 Extending Ant
18 Writing Ant tasks
19 Extending Ant further  

Q: No chapter devoted to TestNG?


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups "testng-users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/testng-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Review of "Developing Java Software"

Steve Loughran-7

products by chapter

> 4 Testing with JUnit

JUnit 3. I'll mention it as the alternative/successor
> 11 Library Management
Ivy.

> 12 Developing for the web
httpunit; point to selenium but no detail.

> 14 Enterprise Java
Cactus. Which is still state of the art in testing server-side code.

> 15 Continuous Integration
Luntbuild
> 16 Deployment
Smartfrog;
>
> Part 3 Extending Ant
> 18 Writing Ant tasks
> 19 Extending Ant further

AntUnit!

I've pulled coverage of Gump from ch15 (no space) and Cargo from ch16,
both of which sadden me. i use the maven ant tasks for ch11
originally, but did a complete rewrite back in october.

> Q: No chapter devoted to TestNG?

No. Sorry. Publishers get nervous when the page count goes above 600,
which Is why I've already had to pull pages on cargo and gump. I also
did hibernate side by side with Java EE for a while, but stopped it.

I will probably eventually add some coverage on the site that will
accompany the book, which is where I will put the cut text and
chapters from the first edition that havent made it over (XDoclet, Web
Services and C++ builds)

Essentially the book focuses on building and deploying with a test
centric philosophy, and doesnt try and be a complete software
engineering with Java tome, which I delegate to anyone else.

To be honest, I am grateful for anything that advocates testing in
junit or testng, compared to books that dont cover the details of
getting something built and working. There's not enough tests in most
organisations, and not enough about testing in technology books. Test
it: go to your nearest bookstore and look at a current book on EJB,
Java EE or the like. Search the index for any coverage on building,
testing or deploying the bunny. Deployment is usually treated as "just
copy it", building is "press build on the IDE", and testing skipped
entirely.

Sigh.

-steve

-steve

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups "testng-users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/testng-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Review of "Developing Java Software"

Russel Winder
On Fri, 2006-12-15 at 21:23 +0000, Steve Loughran wrote:

[ . . . ]

> To be honest, I am grateful for anything that advocates testing in
> junit or testng, compared to books that dont cover the details of
> getting something built and working. There's not enough tests in most
> organisations, and not enough about testing in technology books. Test
> it: go to your nearest bookstore and look at a current book on EJB,
> Java EE or the like. Search the index for any coverage on building,
> testing or deploying the bunny. Deployment is usually treated as "just
> copy it", building is "press build on the IDE", and testing skipped
> entirely.

Graham Roberts and myself are on a campaign to get test-driven
development (TDD) seen as part of the necessary curriculum of
introductory programming.  There are many problems here:

--  the ACM curriculum doesn't have it in, it sees things like TDD as
methods and methods are part of software engineering not programming.

--  most educators have never actually done any real programming
themselves.

--  organizations value `saleable product now' over `quality product
now' and see testing as an overhead since the code is not part of the
product that ships.

For me TDD is not a software engineering method (leave that to
Waterfall, Fountain, XP), it is a programming process.  TDD can be part
of a Waterfall approach, it is not only an Agile Process -- well in fact
it is isn't agile at all it is very strict and rigid :-)

I have not surveyed the fields you mentioned but I can imagine most
trade and professional books are so focused on the technology and the
API that they are not interested in `how does person X actually develop
things using technology Y'.  Actually this is also a problem in
textbooks, most explain the language, they do not guide people to become
proficient in that language.  Reference books are usful for
practitioners but useless for learning and teaching.

Even if used more loosely than classic TDD demands, focusing on unit
tests as a way of defining whether the code works or not is just such a
huge win, I can't see how anyone can argue against it.

The problem is to educate all the `management types' and educators that
unit test code is actually more valuable than direct product code.
--
Russel.
====================================================
Dr Russel Winder                +44 20 7585 2200
41 Buckmaster Road              +44 7770 465 077
London SW11 1EN, UK             [hidden email]

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Review of "Developing Java Software"

Russel Winder
In reply to this post by Steve Loughran-7
On Thu, 2006-12-14 at 11:01 +0000, Steve Loughran wrote:

> Well I for one am glad that an intro to programming book actually
> takes a test centric approach, rather than the
> how-to-use-eclipse-to-make-apps books that are full of nothing but
> screen shots

Splendid.  Graham and I are strong believers in the need for students to
appreciate the need for and value of unit test as part of their overall
code.

The problem is not so much new students, the problem is management and
the system.

The balance between code that is part of the active functionality of
product and the unit testing of that code is currently wrong.  The
former is valued the latter is seen as an overhead.

I guess what is needed is more education of managers that unit tests are
actually probably more important and valuable that product code.

> > 4.  The book uses TestNG 4.7 annotations :-(  We are hoping that this
> > syntax will be supported until we get the 4th edition out!
>
> welcome to the world of book maintenance.

Been there for quite a while :-)

Cédric has said it will not be deleted even though it is deprecated so
that is great.

Graham and I are switching the code on the website to be TestNG 5 code
even though it is then in conflict with the written tome.  I am hoping
it is better to openly acknowledge that the book lags the framework than
it is to try and do any patching and covering over the cracks.

--
Russel.
====================================================
Dr Russel Winder                +44 20 7585 2200
41 Buckmaster Road              +44 7770 465 077
London SW11 1EN, UK             [hidden email]

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Review of "Developing Java Software"

Russel Winder
In reply to this post by Cédric Beust ♔
On Thu, 2006-12-14 at 06:45 -0800, Cédric Beust ♔ wrote:

> On 12/14/06, Russel Winder <[hidden email]> wrote:
>        
>         1.  The book is an introduction to programming (in Java) so I
>         doubt
>         anyone on the TestNG list will ever read it :-)
>
> Probably not but thanks to you, newcomers to Java will be exposed to
> TestNG, which is very good!

That's the idea :-)

There is a serious issue though.  Many, many educators are not really
aware that unit-testing and some variety of TDD is now the norm for the
intelligent and sophisticated programmer.  OK a lot of development
companies don't know this either but...

In putting this textbook out, we are trying to educate the educators as
well as the students.

>         3.  I wonder if TestNG should be in package testng, rather
>         than
>         org.testng ?
>
> No, because it would break things, as Steve pointed out, but also
> because it's non-standard.  Even Sun and JUnit, which were some of the
> last offenders with incorrect package naming, finally fell in line.

OK, sounds fine but leads to a worry unrelated to TestNG.  Groovy,
Grails and Gant are using groovy, grails and gant as top level package
names as well as org.codehaus.groovy, etc. Is this going against an
emerging `rule'?

>         4.  The book uses TestNG 4.7 annotations :-(  We are hoping
>         that this
>         syntax will be supported until we get the 4th edition out!
>
> Don't worry, support for this syntax will never be removed.

Phew :-)

We are updating the code on the website to be TestNG 5 compliant and
explaining that this is evolution and the way the world works -- and it
is a great hook for introducing deprecation!  Hopefully it doesn't have
a counter-productive effect.

We are probably looking at the 4th edition being a Java 7 version -- it
seems reasonable to not worry about Java 6 since the difference between
Java 5 and Java 6 don't really impinge much on people learning Java.
This means a 2008-9 type timescale.   So during the second half of 2007,
we will be surveying the state of things and the likely futures.

--
Russel.
====================================================
Dr Russel Winder                +44 20 7585 2200
41 Buckmaster Road              +44 7770 465 077
London SW11 1EN, UK             [hidden email]

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Review of "Developing Java Software"

Hani Suleiman

Sorry to jump in, but couldn't resist!

On Dec 16, 2006, at 8:15 AM, Russel Winder wrote:

> There is a serious issue though.  Many, many educators are not really
> aware that unit-testing and some variety of TDD is now the norm for  
> the
> intelligent and sophisticated programmer.  OK a lot of development
> companies don't know this either but...
>
I strongly disagree with this. A better assertion is 'testing should  
be the norm for intelligent and sophisticated programmers'. TDD  
itself is a fairly awkward and unintuitive approach that is often  
inapplicable in many projects.

> OK, sounds fine but leads to a worry unrelated to TestNG.  Groovy,
> Grails and Gant are using groovy, grails and gant as top level package
> names as well as org.codehaus.groovy, etc. Is this going against an
> emerging `rule'?

Those projects are basically....wrong ;)

There are established naming conventions for package names. People  
bucking those conventions do so out of ignorance or convenience, but  
it's certain not to be encouraged or adopted!


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups "testng-users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/testng-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Review of "Developing Java Software"

Russel Winder
On Sat, 2006-12-16 at 14:11 +0000, Hani Suleiman wrote:
> Sorry to jump in, but couldn't resist!

Resistance is futile ;-)
 

> On Dec 16, 2006, at 8:15 AM, Russel Winder wrote:
>
> > There is a serious issue though.  Many, many educators are not really
> > aware that unit-testing and some variety of TDD is now the norm for  
> > the
> > intelligent and sophisticated programmer.  OK a lot of development
> > companies don't know this either but...
> >
> I strongly disagree with this. A better assertion is 'testing should  
> be the norm for intelligent and sophisticated programmers'. TDD  
> itself is a fairly awkward and unintuitive approach that is often  
> inapplicable in many projects.
Agreed, I tend to use TDD as a label for a much looser development
process that the TDD label should imply.  Apologies.  Perhaps we can
invent the term UOD -- unit-test oriented development.  TDD is then a
subset of UOD.

For me the important thing is that unit tests are seen as being as
important as the code itself and that coverage is a main metric of
whether a unit test suite is a good one.   I probably don't do TDD as it
is supposed to be practiced but I certainly do UOD.

> > OK, sounds fine but leads to a worry unrelated to TestNG.  Groovy,
> > Grails and Gant are using groovy, grails and gant as top level package
> > names as well as org.codehaus.groovy, etc. Is this going against an
> > emerging `rule'?
>
> Those projects are basically....wrong ;)
>
> There are established naming conventions for package names. People  
> bucking those conventions do so out of ignorance or convenience, but  
> it's certain not to be encouraged or adopted!
So presumably the java top-level package material will soon be moved to
com.sun.java ?

--
Russel.
====================================================
Dr Russel Winder                +44 20 7585 2200
41 Buckmaster Road              +44 7770 465 077
London SW11 1EN, UK             [hidden email]

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Review of "Developing Java Software"

Hani Suleiman

We're getting offtopic, but hopefully this is relevant stuff that's  
interesting to discuss...

On Dec 16, 2006, at 2:58 PM, Russel Winder wrote:

> For me the important thing is that unit tests are seen as being as
> important as the code itself and that coverage is a main metric of
> whether a unit test suite is a good one.   I probably don't do TDD  
> as it
> is supposed to be practiced but I certainly do UOD.
>
I wouldn't place such an emphasis on unit tests. I much prefer the  
'have tests' approach, rather than the unit based one. Functional  
tests are ultimately more valuable in fact, unit tests can exist to  
help you breakdown your functional tests into easy testable units for  
debugging purposes, but they're not required.

In many large system (eg, big integration projects) the units are not  
a concern, they work and are hardly ever the source of bugs. The  
issues all arise from interactions between components. In such cases,  
functional and integration tests make a lot more sense.

In other projects that code closer to 'pure java', where it's easy to  
write unit tests, then unit tests would be written more often than  
functional/integration ones. Both approaches are perfectly valid, and  
neither should strive for more than what happens to make sense for it.

Ultimately, if the tests come naturally, go for it. In many cases  
they don't, and people still try to shoehorn them in.

Finally, coverage is one of the worst things to happen to Java  
testing! People get obsessed with that red/green bar and end up  
writing dozens of pointless tests for code that is often non-critical  
and often is trivial stuff that can't go wrong. Yet time is wasted  
testing it just to bump up that green bar so you can claim you have  
85% coverage.

>> Those projects are basically....wrong ;)
>>
>> There are established naming conventions for package names. People
>> bucking those conventions do so out of ignorance or convenience, but
>> it's certain not to be encouraged or adopted!
>
> So presumably the java top-level package material will soon be  
> moved to
> com.sun.java ?

No, the naming conventions also reserve two namespaces, java.* and  
javax.*


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups "testng-users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/testng-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Review of "Developing Java Software"

Cédric Beust ♔
In reply to this post by Russel Winder


On 12/16/06, Russel Winder <[hidden email]> wrote:
For me the important thing is that unit tests are seen as being as
important as the code itself and that coverage is a main metric of
whether a unit test suite is a good one.   I probably don't do TDD as it
is supposed to be practiced but I certainly do UOD.

Sorry Russel, it's my turn to disagree now :-)

TDD is just a way to do testing.  It's orthogonal to unit, functional or whatever testing.

In short, there are approximately three phases in writing software:  code, unit tests, functional tests.  I don't really care in what order developers choose to code as long as they write tests.

And I certainly do agree with Hani that TDD is a fairly awkward process that is probably never going to become the norm.

--
Cédric
--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups "testng-users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/testng-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Review of "Developing Java Software"

Steve Loughran-7
I'm really enjoying this discussion.

On 16/12/06, Cédric Beust ♔ <[hidden email]> wrote:

>
>
> On 12/16/06, Russel Winder <[hidden email]> wrote:
> > For me the important thing is that unit tests are seen as being as
> > important as the code itself and that coverage is a main metric of
> > whether a unit test suite is a good one.   I probably don't do TDD as it
> > is supposed to be practiced but I certainly do UOD.
>
> Sorry Russel, it's my turn to disagree now :-)
>
> TDD is just a way to do testing.  It's orthogonal to unit, functional or
> whatever testing.
>
> In short, there are approximately three phases in writing software:  code,
> unit tests, functional tests.  I don't really care in what order developers
> choose to code as long as they write tests.
>

Now I have to disagree somewhat, bringing the harsh reality of
development to the table.

There is a phase at the beginning where the idea of what you are going
to build gets imagined. It may be a complete design in  a waterfall
process, it may be a vague wish. Whatever, right from the outset, you
should say "how are you going to test this". If the answer is "we dont
know", you'd better hope the system never needs to be used, as when it
is used it will probably go wrong.

The classic example of this was Reagan's "Star Wars" SDI initiative,
where David Lodge Parnas (http://en.wikipedia.org/wiki/David_Parnas)
resigned from the advisory committee on the grounds that the only way
you'd be able to test a continent wide ballistic missile defense
system would be to go to war with the Soviet Union, and it would be
too late to report any defects then, let alone fix them.

Even in smaller projects, if the designs were produced (and often
standardised) without any thought of testing, you know that they wont
work. Web Services are a case in point here. All the new Ws-* specs
are based on WS-Addressing, and do you know how many tests there were
for this by the time they got standardized? Zero. Just a couple of
emails saying "we should do some tests now its a standard". So this
thing, the successor to the URL, was released as a stable 1.0
specification without any tests.

Which explains why I am sitting here on a saturday evening with my
home linux desktop running tests against a brazilian university
endpoint, as we try and stabilize our implementations of
WS-Notification, a "1.0" spec that actually depends on two different
versions of WS-Addressing.

I cornered my employers W3C TAG member "architect" by the coffee
machine once and gave him a hard time about this. And what did he say?
"We are the W3C architecture group. We dont bother with implementation
details".

It doesn't matter how test centric your implementation is if the
specifications you are basing it on are untestable junk.


*** Any specification without tests shouldn't exist. ***


The other place where you can integrate testing is when a system goes
live, in production or when it gets ships. The majority of production
related problems are configuration related (citations, available), and
they are usually pretty recurrent. If your system has an app server
that needs the login/hostname to the db, then you can be sure that
during development the developers will forget this. They fix it, and
move on. What they should do is write a test, fix it, and leave the
test running. then when they go live, they can run the same unit tests
against the production system.

This isnt code you are testing, its the configuration of the local box.

You can see some of it in ant -diagnostics, where in ant1.7 it creates
(big) files in the java.io.tmp dir and verifies the file has the right
size and its timestamp isnt too far off the system clock. I think for
ant1.7.1 I'll see if I can nslookup the proxy server and tell off the
end users for setting up ant's proxy settings to point to a
nonexistent host. Ant 1.7Beta 2 encountered a lot of proxy settings on
Java1.5, see.

*** Any deployment without tests isn't replicable ***

To summarize: specs and deployment need testing too, and they both
need to be brought into the iterative development cycle,. But
deployment is left to the ops team, and the specifications come from
"the architects", who have a definite tendency to be developers who
stopped coding 5+ years ago, and wouldn't know a test case if it bit
them.

-Steve

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups "testng-users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/testng-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Review of "Developing Java Software"

Steve Loughran-7
In reply to this post by Russel Winder

On 16/12/06, Russel Winder <[hidden email]> wrote:
>
> The problem is not so much new students, the problem is management and
> the system.

I gave a lecture on testing to the local universities CS course; you
may enjoy the slides (and you can have the PPT template + font if you
want to use it)

http://people.apache.org/~stevel/slides/testing.pdf


> The balance between code that is part of the active functionality of
> product and the unit testing of that code is currently wrong.  The
> former is valued the latter is seen as an overhead.
>
> I guess what is needed is more education of managers that unit tests are
> actually probably more important and valuable that product code.

I discuss this in my talks. The barrier to developer takeup is:
 1-ignorance of how trivial it is to write basic tests
 2-lack of experience of how to write good tests
 3-belief/knowledge that management want 'code' ahead of tests

(3) is not unusal. I've had big problems working with people who
believe that time spent working on tests is wasted. Fighting these
people is one option, but I've discovered another one.

                                                 Lie.

The managers who gave up coding when debugging was the only way to
show something worked can relate to the concept of "debugging" or
"trying to track down a bug". So call the time spent on testing that.
They dont understand or care about the details, so bother their little
heads with modern development practices and processes.

>
> > > 4.  The book uses TestNG 4.7 annotations :-(  We are hoping that this
> > > syntax will be supported until we get the 4th edition out!
> >
> > welcome to the world of book maintenance.
>
> Been there for quite a while :-)
>

If you put your sample code up on a public CVS/SVN repository, I can
add it to gump and you can be the second book whose code is built and
tested against the CVS/SVN_HEAD of everything every night. Its a good
way to report bugs to the upstream teams. "you broke my book!"

-Steve

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups "testng-users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/testng-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Review of "Developing Java Software"

Alexandru Popescu ☀
In reply to this post by Steve Loughran-7
Steve I must confess that these type of statements are really making me afraid:

"Whatever, right from the outset, you
should say "how are you going to test this". If the answer is "we dont
know", you'd better hope the system never needs to be used, as when it
is used it will probably go wrong."

"** Any specification without tests shouldn't exist. ***"

I find this "zealotry" quite bad for the industry and for developers
in general. Everybody agrees that "having tests" is very important,
but I really don't see any benefit in stepping over the edge and
stating things like the above. I have worked for companies that have
successfully delivered successful systems with just a couple of tests
- that are still in productions and with very low bug reports during
5-6 years. I am not saying that this should be the norm, but I
completely disagree with above statements.

./alex
--
.w( the_mindstorm )p.
  TestNG co-founder
EclipseTestNG Creator


On 12/16/06, Steve Loughran <[hidden email]> wrote:

> I'm really enjoying this discussion.
>
> On 16/12/06, Cédric Beust ♔ <[hidden email]> wrote:
> >
> >
> > On 12/16/06, Russel Winder <[hidden email]> wrote:
> > > For me the important thing is that unit tests are seen as being as
> > > important as the code itself and that coverage is a main metric of
> > > whether a unit test suite is a good one.   I probably don't do TDD as it
> > > is supposed to be practiced but I certainly do UOD.
> >
> > Sorry Russel, it's my turn to disagree now :-)
> >
> > TDD is just a way to do testing.  It's orthogonal to unit, functional or
> > whatever testing.
> >
> > In short, there are approximately three phases in writing software:  code,
> > unit tests, functional tests.  I don't really care in what order developers
> > choose to code as long as they write tests.
> >
>
> Now I have to disagree somewhat, bringing the harsh reality of
> development to the table.
>
> There is a phase at the beginning where the idea of what you are going
> to build gets imagined. It may be a complete design in  a waterfall
> process, it may be a vague wish. Whatever, right from the outset, you
> should say "how are you going to test this". If the answer is "we dont
> know", you'd better hope the system never needs to be used, as when it
> is used it will probably go wrong.
>
> The classic example of this was Reagan's "Star Wars" SDI initiative,
> where David Lodge Parnas (http://en.wikipedia.org/wiki/David_Parnas)
> resigned from the advisory committee on the grounds that the only way
> you'd be able to test a continent wide ballistic missile defense
> system would be to go to war with the Soviet Union, and it would be
> too late to report any defects then, let alone fix them.
>
> Even in smaller projects, if the designs were produced (and often
> standardised) without any thought of testing, you know that they wont
> work. Web Services are a case in point here. All the new Ws-* specs
> are based on WS-Addressing, and do you know how many tests there were
> for this by the time they got standardized? Zero. Just a couple of
> emails saying "we should do some tests now its a standard". So this
> thing, the successor to the URL, was released as a stable 1.0
> specification without any tests.
>
> Which explains why I am sitting here on a saturday evening with my
> home linux desktop running tests against a brazilian university
> endpoint, as we try and stabilize our implementations of
> WS-Notification, a "1.0" spec that actually depends on two different
> versions of WS-Addressing.
>
> I cornered my employers W3C TAG member "architect" by the coffee
> machine once and gave him a hard time about this. And what did he say?
> "We are the W3C architecture group. We dont bother with implementation
> details".
>
> It doesn't matter how test centric your implementation is if the
> specifications you are basing it on are untestable junk.
>
>
> *** Any specification without tests shouldn't exist. ***
>
>
> The other place where you can integrate testing is when a system goes
> live, in production or when it gets ships. The majority of production
> related problems are configuration related (citations, available), and
> they are usually pretty recurrent. If your system has an app server
> that needs the login/hostname to the db, then you can be sure that
> during development the developers will forget this. They fix it, and
> move on. What they should do is write a test, fix it, and leave the
> test running. then when they go live, they can run the same unit tests
> against the production system.
>
> This isnt code you are testing, its the configuration of the local box.
>
> You can see some of it in ant -diagnostics, where in ant1.7 it creates
> (big) files in the java.io.tmp dir and verifies the file has the right
> size and its timestamp isnt too far off the system clock. I think for
> ant1.7.1 I'll see if I can nslookup the proxy server and tell off the
> end users for setting up ant's proxy settings to point to a
> nonexistent host. Ant 1.7Beta 2 encountered a lot of proxy settings on
> Java1.5, see.
>
> *** Any deployment without tests isn't replicable ***
>
> To summarize: specs and deployment need testing too, and they both
> need to be brought into the iterative development cycle,. But
> deployment is left to the ops team, and the specifications come from
> "the architects", who have a definite tendency to be developers who
> stopped coding 5+ years ago, and wouldn't know a test case if it bit
> them.
>
> -Steve
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups "testng-users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/testng-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Review of "Developing Java Software"

Steve Loughran-7

On 16/12/06, Alexandru Popescu <[hidden email]> wrote:

> Steve I must confess that these type of statements are really making me afraid:
>
> "Whatever, right from the outset, you
> should say "how are you going to test this". If the answer is "we dont
> know", you'd better hope the system never needs to be used, as when it
> is used it will probably go wrong."
>
> "** Any specification without tests shouldn't exist. ***"
>
> I find this "zealotry" quite bad for the industry and for developers
> in general. Everybody agrees that "having tests" is very important,
> but I really don't see any benefit in stepping over the edge and
> stating things like the above. I have worked for companies that have
> successfully delivered successful systems with just a couple of tests
> - that are still in productions and with very low bug reports during
> 5-6 years. I am not saying that this should be the norm, but I
> completely disagree with above statements.
>
> ./alex

Sorry. I really meant "Any standard without tests shouldnt exist".

That is, no standards body should sign off as a normative
specification something for which there is no way to say "we are
compliant". Without that, all you can say is "we are compatible with
implementation Y", which addresses interop with one other node, but
does not guarantee that either implementation matches the spec. It
also means that if two implementations do not interoperate, they are
left pointing the blame at each other. There's no normative way to
assign blame.

As a case in point, Apache Axis. Sun and MS  SOAP stacks have slighlty
different ways of handling bits of WSDL. There's ambiguities in the
WSDL 1.1 "standard", and they are interpreted differently. If you are
trying to communicate between SOAP stacks you end up discovering these
problems, which cause many hours of fun. There's no individual
implementation you can blame -they are all compliant with the spec-
but they dont interoperate perfectly. Now whole organisations (WS-I)
and W3C working groups (W3C XSD data binding) are being set up to deal
with these problems.

I do think standards can be done differently. You can write tests
alongside the spec, you can automate testing of many parts of the
spec:
http://deployment.cvs.sourceforge.net/*checkout*/deployment/deployment/doc/testing/testing_a_specification.doc

What I don't cover in that doc is how much resistance you encounter
from individuals who want timely bits of paper over something that
could actually be made to work, or from organisations who don't think
the role of a standards body is to produce tests.

-steve

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups "testng-users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/testng-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Review of "Developing Java Software"

Hani Suleiman
In reply to this post by Steve Loughran-7


On Dec 16, 2006, at 9:12 PM, Steve Loughran wrote:

> Now I have to disagree somewhat, bringing the harsh reality of
> development to the table.
>
<snip>

> Even in smaller projects, if the designs were produced (and often
> standardised) without any thought of testing, you know that they wont
> work. Web Services are a case in point here. All the new Ws-* specs
> are based on WS-Addressing, and do you know how many tests there were
> for this by the time they got standardized? Zero. Just a couple of
> emails saying "we should do some tests now its a standard". So this
> thing, the successor to the URL, was released as a stable 1.0
> specification without any tests.
>
A case in point for the exact opposite in fact is the majority of  
projects out there. We (my company) have MANY projects deployment in  
production systems, handling millions of dollars of transactions  
(cliche I know) with nary a test in sight. In fact, the testability  
of the code was not a consideration at all at any phase of the  
project. What was explicit though is the need for a QA team to sign  
off on any releases.

The 'specification' is a business requirements document, with no  
thought on how it should be tested. Actual testing is ad-hoc, with  
the QA dept managing their own documents and enhancing them as they  
find issues, for things to look out for in every release.

Maybe I work in a particularly retarded industry, but that's by far  
the norm. My company wouldn't get half the projects we get if we  
doubled our delivery deadlines because we need to now write a bunch  
of tests. Ultimately, tests are a luxury, not a necessity. Yes, it's  
nice to have them. Yes, it makes life more comfortable. Yes, they pay  
off in terms of manpower and costs eventually, but getting the  
initial buy in is far from an implicit assumption.

> *** Any specification without tests shouldn't exist. ***
>
Sure, as a member of the JCP, I agree wholeheardly. In fact, no JSR  
can exist without a TCK, it's part of the required deliverables. How  
many projects though are about writing formal specifications? An  
statistically insignificant number. Most projects out there are there  
to achieve a specific business goal.

>
> The other place where you can integrate testing is when a system goes
> live, in production or when it gets ships. The majority of production
> related problems are configuration related (citations, available), and
> they are usually pretty recurrent. If your system has an app server
> that needs the login/hostname to the db, then you can be sure that
> during development the developers will forget this. They fix it, and
> move on. What they should do is write a test, fix it, and leave the
> test running. then when they go live, they can run the same unit tests
> against the production system.
>
> This isnt code you are testing, its the configuration of the local  
> box.
>
Yes, which by its very nature is not easily testable, because tests  
if anything make the situation worse by pretending there's a known  
environment, when in fact you never know what sort of  
misconfiguration the live box has. There's nothing more evil than a  
test which passes because it just so happens to set up a fake  
unrealistic environment that just accidentally matches the nightly CI  
machine.

> *** Any deployment without tests isn't replicable ***
>
Nonsense! I can tag a version in my source control system. Building  
that tag results in the same artifacts. In fact, if you want to be  
anal about it you could commit the artifacts themselves. The tests  
are completely orthogonal to deployment, unless I'm missing something!

>  and the specifications come from
> "the architects", who have a definite tendency to be developers who
> stopped coding 5+ years ago, and wouldn't know a test case if it bit
> them.

Yes, the the testability of code is a luxury, not a necessity. It's  
nice to be able to test stuff, but it's not required for success or  
adoption. Want some examples? Servlets and even worse, JSP pages.  
It's impossible to test the latter for example, and JSF is even  
worse. The specification authors wouldn't know the difference between  
a spec and an implement if it painted itself purple and danced around  
them naked single kumbaya my lord, yet both are wildly successful.  
How do you explain that?



--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups "testng-users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/testng-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Review of "Developing Java Software"

bklau
In reply to this post by Russel Winder

Russel Winder wrote:

> On Thu, 2006-12-14 at 11:01 +0000, Steve Loughran wrote:
>
> > Well I for one am glad that an intro to programming book actually
> > takes a test centric approach, rather than the
> > how-to-use-eclipse-to-make-apps books that are full of nothing but
> > screen shots
>
> Splendid.  Graham and I are strong believers in the need for students to
> appreciate the need for and value of unit test as part of their overall
> code.
>
> The problem is not so much new students, the problem is management and
> the system.

I think both.
Students(developers) think that testing is menial and command
only "second-class citizen" respect.
Managements like their politician peers knows that a shipped products
brings about
revenue booking, promotions, bonus and a good resume line for next job
hop.
Expedient is the now in the in-practice over "engineering correctness",
which includes testing and processes. A shipped product is "visible"
and obvious but a list of defects caught and fixed is harder to sell,
so to speak.
>
> The balance between code that is part of the active functionality of
> product and the unit testing of that code is currently wrong.  The
> former is valued the latter is seen as an overhead.
A unit test suite's return-on-investment value comes later in the 2, 3
or 4th product releases where bugs fixes and/or modification needs a
regression. This is more important, consider that most members of
original development may have moved on to other projects or to a new
company and less resource is allocated to code maintainence.
Outsourcing only reinforced this "mercenary attitude".

>
> I guess what is needed is more education of managers that unit tests are
> actually probably more important and valuable that product code.
>
> > > 4.  The book uses TestNG 4.7 annotations :-(  We are hoping that this
> > > syntax will be supported until we get the 4th edition out!
> >
> > welcome to the world of book maintenance.
>
> Been there for quite a while :-)
>
> Cédric has said it will not be deleted even though it is deprecated so
> that is great.
>
> Graham and I are switching the code on the website to be TestNG 5 code
> even though it is then in conflict with the written tome.  I am hoping
> it is better to openly acknowledge that the book lags the framework than
> it is to try and do any patching and covering over the cracks.
>
> --
> Russel.
> ====================================================
> Dr Russel Winder                +44 20 7585 2200
> 41 Buckmaster Road              +44 7770 465 077
> London SW11 1EN, UK             [hidden email]
>
> --=-bpDBF6LjMMns8Mz43Xzx
> Content-Type: application/pgp-signature
> Content-Disposition: inline;
> filename="signature.asc"
> Content-Description: This is a digitally signed message part
> X-Google-AttachSize: 190


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups "testng-users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/testng-users?hl=en
-~----------~----~----~----~------~----~------~--~---

12