I'm trying out a way of forward referencing from the Process part into
the Example.

See the "where do objects come from" section in

http://www.mockobjects.com/achieving-oo-design.pdf

What do people think?

Otherwise, I'm inclined to just delete the references.

S

Steve Freeman
Winner of the Agile Alliance Gordon Pask award 2006

http://www.m3p.co.uk

M3P Limited.
Registered office. 2 Church Street, Burnham, Bucks, SL1 7HZ.
Company registered in England & Wales. Number 03689627

I like the forward references, for me it helps me see the overall picture.
"an interface describes
whether two components will fit together, a protocol describes whether they will
work together." this one is a gem.

Cheers
Isaiah
--- In growing-oo-software-guided-by-tests@yahoogroups.com, Steve Freeman
<steve@...> wrote:
>
> I'm trying out a way of forward referencing from the Process part into
> the Example.
>
> See the "where do objects come from" section in
>
> http://www.mockobjects.com/achieving-oo-design.pdf
>
> What do people think?
>
> Otherwise, I'm inclined to just delete the references.
>
> S
>
> Steve Freeman
> Winner of the Agile Alliance Gordon Pask award 2006
>
> http://www.m3p.co.uk
>
> M3P Limited.
> Registered office. 2 Church Street, Burnham, Bucks, SL1 7HZ.
> Company registered in England & Wales. Number 03689627
>

Added parens instead

On 7 Jul 2009, at 19:31, yap_noel wrote:
> "rather than having to maintain a mental model of all the code at
> once, and merging changes back in is never a crisis." -> "rather
> than having to maintain a mental model of all the code at once; and
> merging changes back in is never a crisis." ?

Done, thanks


On 7 Jul 2009, at 19:22, yap_noel wrote:

On 9 Jul 2009, at 17:26, isaiahperumalla wrote:
> I like the forward references, for me it helps me see the overall
> picture.

good.

> "an interface describes
> whether two components will fit together, a protocol describes
> whether they will
> work together." this one is a gem.

heard at ACCU

S.

--- In growing-oo-software-guided-by-tests@yahoogroups.com, Steve Freeman
<steve@...> wrote:
>
> I'm trying out a way of forward referencing from the Process part into
> the Example.

I think it's much more clear now.

You could also check the corresponding backward references to be sure they are
bidirectional.
For example your "looking ahead" on page 4 points to AuctionMessageTranslator,
on pages 104, 105 (07 July 2009 version) whereas corresponding backward
reference points to page 45 - "As we wrote in "Designing for Maintainability"
(page 45), we want to maintain a Separation of Concerns.  At least you should
add a  backward reference to corresponding "looking ahead" on page 4 (achieving
– OO-design, 9 July 2009).

Vladimir.

2009/7/6 Dave Smith <davewsmith@...>:
> From your description, and looking at the 24 June draft, I'm still not
> seeing
> it, unless there's now a JVM guarantee that flushes that are larger than an
> int
> (i.e., the reference that count holds) are inherently synchronized. (I
> learned
> the rules back in 1.1 days, and quite probably missed any update.)

The language spec v.3 specifies that all of a thread's cached
variables are sync'd with main memory when it leaves a synchronized
block (as far as I understand it, and the tests did all pass).

> Synchronizing count() makes it very clear. Thanks.

Clarity is more important than obscure code that shaves a few
milliseconds off run-time.  Thanks for the feedback.

--Nat

--
http://www.natpryce.com

2009/7/1 Dave Smith <davewsmith@...>:
> "An auction Search Object will not pass empty lists of search results to the
> consumer."  I couldn't find where in code this was enforced.

This was left over from a previous version of the example code.  I've
removed mention of it now.

I've addressed all your other points (including the braces vs.
suspenders issue!).

Thanks,
     --Nat.

--
http://www.natpryce.com

2009/7/1 Dave Smith <davewsmith@...>:
> Oen reviewer's comment was "If
> this is the state-of-the-art in testing, I'm depressed about it."  Not sure
> how actionable that is, though.

Oh dear :-(

I think that the techniques in this chapter, or rather their
limitations, are caused by the inherent qualities of distributed
systems. You cannot get a global snapshot of a system's state and, to
detect failure, you have to rely on local timeouts. Often we can
pretend that this is not happening and treat our interaction with a
distributed system as synchronous -- e.g. HTTP -- but in those cases
we're just relying on a transport connection to perform the timeouts
for us. When we cannot use lower layers to create this illusion, we
have to implement it in our tests and how we do so is usually
system-specific, I find.

Whether it is state of the art, I'm not sure.  I've not found much
literature about the subject. Vendor tools for system testing are very
brittle and don't support test-first development very well, which is
why we had to write our own.  This chapter is a distillation of what
we learned doing that on several projects. It's a small step forward
to help address what I find many projects end up with -- flickering
tests, race conditions that mean tests are not really testing
anything, ad hoc synchronisation code scattered around their tests,
sleeps, long running tests, etc.

> Bill Venners points to Bill Pugh's "Multi-Threaded TC" as something to check
> out to assist with asynchronous testing.

This acts at a much finer grain than the tests we're discussing in the
Async' chapter. The techniques in the Asynchronous Testing chapter
came from writing coarse-grained tests, such as system-tests of
distributed systems that build with several languages upon third-party
open-source and vendor products, running on different platforms. For
example, on one of our projects the smallest cut-down version of the
system we could deploy had a dozen or so processes running on Windows
and Unix and a full deployment involved hundreds of calculation
engines, market data services and cache servers deployed around the
world.

Perhaps MultithreadedTC would fit better in the unit testing with
threads chapter.  I doubt we'll have time to address it in depth this
close to the deadline but it's definitely worth mentioning.  It's very
cool.

--Nat

--
http://www.natpryce.com

--- In growing-oo-software-guided-by-tests@yahoogroups.com, "nat_pryce"
<nat.pryce@...> wrote:
>
> Hi all.  There's now quite a few people in this group, some of whom we
> don't know (or we don't recognise your Yahoo IDs).  Time for
> introductions!
>
> Please reply, telling us who you are and what your background and
> experience is.
>
> Here's my bio to kick things off:
>
> I am Nat Pryce.  I develop software and provide consultancy and
> training in software design and development process and practices,
> mostly in the finance and telecoms industries. I'm also a part-time
> research fellow at Imperial College where I study privacy in mobile
> systems and do occasional teaching.
>
> I have about 15 years experience in the industry, in a variety of
> systems and languages, ranging from C for tiny mote devices to Java in
> global enterprise integration systems with all sorts of wierder
> languages in between.
>
> I'm one of the authors of the jMock unit-testing framework and the
> WindowLicker GUI testing framework.
>
> I (occasionally) blog at http://nat.truemesh.com.
>


Hello I'm Chris Wash - I'm a software developer from Richmond Virginia.  I've
been working in Java for the past 9 years and have been doing consulting for the
past 5 years.  I mostly work with traditional n-tier applications, in particular
those deployed via the web.  I also have tinkered with other languages and
platforms, though nothing professionally.

My current technology interests center around JSR-299 (JCDI, its RI "WebBeans"
and ancestor projects Seam and Guice).  I'm also quite interested in testing as
it pertains to developers as an engineering practice.  I also must admit I've
fallen victim to the buzz around modularity (on the Java platform) of late and
am very interested in that space as.

I keep a blog of my misadventures at http://cwash.org.

Hope I haven't joined this conversation too late to be of help!

Is the copy editor "black box" or is it interactive?

Pete

On Wed, July 8, 2009 16:50, Steve Freeman wrote:
> OK. We'll let the copy editor settle this one :)
>
> thanks
>
> S.
>
> On 8 Jul 2009, at 22:45, Wayne Vucenic wrote:
>> On Wed, Jul 8, 2009 at 3:15 AM, Steve Freeman <steve@...> wrote:
>>
>>>> "to agree some basic terms" -> "to agree on some basic terms"
>>>> "we've agreed a rough version" -> "we've agreed to a rough version"
>>
>>> Usage seems to differ on this one. The original is valid.
>>
>> I believe this is the UK English vs. US English issue we've discussed
>> before.  Regardless, to this US speaker the originals sound so
>> incorrect as
>> to disrupt my flow of thought while reading.  You may want to change
>> to
>> different phrases that work well for both US and UK readers.

I'm halfway through reworking the cheat-sheet.

http://www.mockobjects.com/jmock2-cheat-sheet.pdf

Are people happy with the progress so far, in particular the
explanation of the feared double braces?

Ta

S.

He's actually Canadian, so he's neutral :)

S.

On 8 Jul 2009, at 23:48, Pete Keller wrote:
> Is the copy editor "black box" or is it interactive?
>
> Pete
>
> On Wed, July 8, 2009 16:50, Steve Freeman wrote:
>> OK. We'll let the copy editor settle this one :)

So you can send him both sides of the argument and give him choices then?

On Fri, July 10, 2009 11:29, Steve Freeman wrote:
> He's actually Canadian, so he's neutral :)
>
> S.
>
> On 8 Jul 2009, at 23:48, Pete Keller wrote:
>> Is the copy editor "black box" or is it interactive?
>>
>> Pete
>>
>> On Wed, July 8, 2009 16:50, Steve Freeman wrote:
>>> OK. We'll let the copy editor settle this one :)

cheat sheet reworked.

http://www.mockobjects.com/jmock-cheat-sheet.pdf

Let me know if this is not enough.

Thanks

S.

On 11 Jul 2009, at 17:57, Dave Smith wrote:

>
>
> On Sat, Jul 11, 2009 at 9:39 AM, Steve Freeman <steve@...>
> wrote:
> cheat sheet reworked.
>
> http://www.mockobjects.com/jmock-cheat-sheet.pdf
>
> Let me know if this is not enough.
>
> That link 404s, and I'm not seeing it on Google sites.

I'm guessing it's

http://www.mockobjects.com/jmock2-cheat-sheet.pdf


Matt Wynne
http://blog.mattwynne.net
http://www.songkick.com

Pdf version 7 july 2009.I created an Eclipse 3.4.2 project for the code of
chapter 11 (with JUnit 4.4 on the class path)

1) Class AuctionSniperDriver.

A)
In the "hasText(equalTo(statusText)": the origin of the method "equalTo(...) is
not clear.

( Luckily I had the sources of WindowLicker in my workspace to realize that I
needed (as in  JFrameDriver) the import:
import static org.hamcrest.Matchers.equalTo;
Eclipse does not help with it even if Matchers.class is put on the build path.
When explaining the class  FakeAuctionServer (later !),  you give a reference to
"Methods And Expectations" (page 323) to comment the use of  is(notNullValue().
Even in the example (method indexesEntriesByName()) on the page 23, it's not
clear that equalTo is a method of Mathchers.)

This is a general problem (already mentioned in the forum) of the readability of
your code. It  will be nice to comment where classes come from.

B)
In startSellingItem, to be clear and/or coherent with the rest, "format" must be
qualified by String.format.


2) Classe SingleMessageListener
Even if you reference the java.util.concurrent package in the text, it would be
nice to comment the exact origin of SECONDS (import static
java.util.concurrent.TimeUnit.SECONDS;)

3) The class Main referenced in the code before launching the first test is not
explained (so formally the code as just before Failing And Passing the Test,
page 88,  is not compiled)

Vladimir.

JUnit's version which come with  Eclipse 3.4.2 is 4.3. The method assertThat
does not exist in the class Assert of JUnit 4.3 but it exists in MatcherAssert.
This can create an confusion in the code of  SingleMessageListener (page 87) and
in Test Fixtures on page 23

So it would be nice (for the future reader) from you to precise (in Chapter 3.
An Introduction to the Tools) that the minimal version of JUnit 4 is 4.4.

Pdf version 7 july 2009.I created an Eclipse 3.4.2 project for the code of
chapter 11.
I have a Vista, French version, and the French keyboard on my laptop.

Page 89: When I launch the first test "AuctionSniperEndToEndTest » (over a
compiled code) I have an error

java.lang.IllegalArgumentException: keyboard layout FR not available.
	 at 
com.objogate.wl.keyboard.KeyboardLayout.getKeyboardLayout(KeyboardLayout.java:82\
)
	 at
com.objogate.wl.keyboard.KeyboardLayout.getDefaultKeyboardLayout(KeyboardLayout.\
java:75)
	 at com.objogate.wl.robot.RoboticAutomaton.<init>(RoboticAutomaton.java:27)
	 at
com.objogate.wl.swing.gesture.GesturePerformer.<init>(GesturePerformer.java:13)
	 at livre.main.AuctionSniperDriver.<init>(AuctionSniperDriver.java:11)
	 at livre.main.ApplicationRunner.startBiddingIn(ApplicationRunner.java:25)
	 at
livre.test.AuctionSniperEndToEndTest.sniperJoinsAuctionUntilAuctionCloses(Auctio\
nSniperEndToEndTest.java:16)

I don't know WindowLicker nor its build process and it seems to me that there is
no executable distribution on google site (so I could build bad jars), and that
there is no FR.keayboard or something like this in com.objogate.wl.keyboard
package (I only found US and UK).

If this is true then the book will not be FULLY available for French readers.

Vladimir

Pdf version 7 july 2009.I created an Eclipse 3.4.2 project for the code of chapter 11.
I have a Vista, French version, and the French keyboard on my laptop.

Page 89: When I launch the first test "AuctionSniperEndToEndTest Â» (over a compiled code) I have an error

java.lang.IllegalArgumentException: keyboard layout FR not available.
at com.objogate.wl.keyboard.KeyboardLayout.getKeyboardLayout(KeyboardLayout.java:82)
at com.objogate.wl.keyboard.KeyboardLayout.getDefaultKeyboardLayout(KeyboardLayout.java:75)
at com.objogate.wl.robot.RoboticAutomaton.<init>(RoboticAutomaton.java:27)
at com.objogate.wl.swing.gesture.GesturePerformer.<init>(GesturePerformer.java:13)
at livre.main.AuctionSniperDriver.<init>(AuctionSniperDriver.java:11)
at livre.main.ApplicationRunner.startBiddingIn(ApplicationRunner.java:25)
at livre.test.AuctionSniperEndToEndTest.sniperJoinsAuctionUntilAuctionCloses(AuctionSniperEndToEndTest.java:16)

I don't know WindowLicker nor its build process and it seems to me that there is no executable distribution on google site (so I could build bad jars), and that there is no FR.keayboard or something like this in com.objogate.wl.keyboard package (I only found US and UK).

If this is true then the book will not be FULLY available for French readers.

Vladimir

> So it would be nice (for the future reader) from you to precise (in
> Chapter 3. An Introduction to the Tools) that the minimal version of
> JUnit 4 is 4.4.

Done. We're using 4.6

S.

We'll have to think about this. Don't forget that our intention is to
have the code available for download and browsing by the time of
publication.

S.

On 13 Jul 2009, at 19:09, vladimir.trofimov wrote:

> Pdf version 7 july 2009.I created an Eclipse 3.4.2 project for the
> code of chapter 11 (with JUnit 4.4 on the class path)
>
> 1) Class AuctionSniperDriver.
>
> A)
> In the "hasText(equalTo(statusText)": the origin of the method
> "equalTo(...) is not clear.
>
> ( Luckily I had the sources of WindowLicker in my workspace to
> realize that I needed (as in  JFrameDriver) the import:
> import static org.hamcrest.Matchers.equalTo;
> Eclipse does not help with it even if Matchers.class is put on the
> build path.
> When explaining the class  FakeAuctionServer (later !),  you give a
> reference to "Methods And Expectations" (page 323) to comment the
> use of  is(notNullValue().
> Even in the example (method indexesEntriesByName()) on the page 23,
> it's not clear that equalTo is a method of Mathchers.)
>
> This is a general problem (already mentioned in the forum) of the
> readability of your code. It  will be nice to comment where classes
> come from.
>
> B)
> In startSellingItem, to be clear and/or coherent with the rest,
> "format" must be qualified by String.format.
>
>
> 2) Classe SingleMessageListener
> Even if you reference the java.util.concurrent package in the text,
> it would be nice to comment the exact origin of SECONDS (import
> static java.util.concurrent.TimeUnit.SECONDS;)
>
> 3) The class Main referenced in the code before launching the first
> test is not explained (so formally the code as just before Failing
> And Passing the Test, page 88,  is not compiled)

> §5 Remark.
>
> You write in "Building Up To Higher-Level Programming":
>
> "The design forces, of course, will be different in the few
> languages that support multiple inheritance well, such as Eiffel
> [Meyer1991] ".
> Is it a way to say that C++ `s support is bad ?

yes :)

S

--- In growing-oo-software-guided-by-tests@yahoogroups.com, Steve Freeman
<steve@...> wrote:
>
> We'll have to think about this. Don't forget that our intention is to
> have the code available for download and browsing by the time of
> publication.

To make the code "as just before Failing And Passing the Test, page 88"
compilable, Eclipse proposes me the minimal version
public class Main {

	 public static final String MAIN_WINDOW_NAME = null;
	 public static final String SNIPER_STATUS_NAME = null;

	 public static void main(String xmppHostname, String sniperId,
			 String sniperPassword, String itemId) {
		 // TODO Auto-generated method stub

	 }

}

With this code the test failure looks like

java.lang.AssertionError:
Tried to look for...
     exactly 1 JFrame (with name NULL and showing on screen)
     in all top level windows

and not like

java.lang.AssertionError:
Tried to look for...
exactly 1 JFrame (with name "Auction Sniper Main" and showing on screen)
in all top level windows

The difference is not very important but it's a bit irritating for a reader who
would like to have  exactly the same code at the time of launching the tests. It
suffices to initialize MAIN_WINDOW_NAME with "Auction Sniper Main". On the
contrary your second "virtual" iteration, or your global source code for the
whole project, does much more at the level of Main class: not only 
MAIN_WINDOW_NAME = "Auction Sniper Main"  but it also initializes JFrame, so the
reader will never see the first failure exactly as it's described in the book.

All this is just to say that the global code available for downloading will not
be good enough for a book describing an iterative process (don't forget that
it's your GROWING OO software). As it was already proposed somewhere on the
discussion list, it would be much  more "pedagogical" to organize the book code
as a number of (Eclipse or whatsoever) projects corresponding to steps or
iterations of the GROWING Sniper application. The level of granularity of thess
steps is a question of supporting tools, taste and cost. There exists already
books which code is organized in this manner (for example Eclipse AspectJ by
A.Colyer and al.).
The rule of thumb: the reader must be able to edit his "exercise" code between
two increments being guided only by the code of the previous iteration and by
explanations given in the text of the book(= delta). When encountering
difficulties (case of the beginning level reader) the reader could search for a
solution in the  code of the next iteration but never in the global and
definitive code noised by an unnecessary complexity.
It would be interesting (certainly for the second edition of your FANTASTIC
book) to try to implement this approach via a SVN server: an increment is equals
to a svn version. In addition there you will have a branch's, fork's and, folk's
support for free, won't you ?

Vladimir.

On 19 Jul 2009, at 13:26, vladimir.trofimov wrote:
> --- In growing-oo-software-guided-by-tests@yahoogroups.com, Steve
> Freeman <steve@...> wrote:With this code the test failure looks like
>
> java.lang.AssertionError:
> Tried to look for...
>    exactly 1 JFrame (with name NULL and showing on screen)
>    in all top level windows
>
> and not like
>
> java.lang.AssertionError:
> Tried to look for...
> exactly 1 JFrame (with name "Auction Sniper Main" and showing on
> screen)
> in all top level windows

Yes. That reporting code is still in a branch. We haven't had time to
merge it into head -- you know why:)

> All this is just to say that the global code available for
> downloading will not be good enough for a book describing an
> iterative process (don't forget that it's your GROWING OO software).
> As it was already proposed somewhere on the discussion list, it
> would be much  more "pedagogical" to organize the book code as a
> number of (Eclipse or whatsoever) projects corresponding to steps or
> iterations of the GROWING Sniper application. The level of
> granularity of thess steps is a question of supporting tools, taste
> and cost. There exists already books which code is organized in this
> manner (for example Eclipse AspectJ by A.Colyer and al.).

That was our intention. We use this material for teaching too.

S.




Steve Freeman
Winner of the Agile Alliance Gordon Pask award 2006

http://www.m3p.co.uk

M3P Limited.
Registered office. 2 Church Street, Burnham, Bucks, SL1 7HZ.
Company registered in England & Wales. Number 03689627