An interview with Nat Pryce #TDDIsEvolving

[philip schwarz]

Google Hangout on Jun 11th at 10pm GMT https://plus.google.com/events/chmrkjcd63vfto5ocojd1gkuum4

Watch to find out:
-- What is the evolution of TDD, BDD, GOOS and software testing design?
-- Good and bad practices when using mocks
-- Testing a Microservices architecture
-- What's the role of testing tools in the process?
-- More opinions about the #IsTDDDead debate
-- What are the trends that will help lead the future in this area? 

[Grzegorz Gałęzowski]

Philip, thank you for posting the link and Nat, thank you very much for sharing your views. I took about 12 poitns of notes from the interview and shared with my team. Things both about microservices and about mocks (especially about the part concerning small, reusable and common interfaces and making many objects compatible with them so that they can be plugged in different places).

Looks like what I still need to learn is how to distinguish between peers and internals. I can spot obvious internals (like collections, some library objects etc. or plain utility code making up for some deficiencies of the language), but I am having trouble getting farther than that. And, while I think I understand the rule of "composite simpler than the sum of parts", it does not help me too much distinguishing between peers and internals... Maybe a future edition of GOOS could contain an expanded discussion on this topic and more examples if this is a common point of understanding (and, judging from the interview, it may be)?

Best regards and thank you again!

grzesiek

[Grzegorz Gałęzowski]

Sorry, I meant "common point of misunderstanding" instead of "common point of understanding" :-).

[Josue Barbosa dos Santos]

>>Looks like what I still need to learn is how to distinguish 

>>between peers and internals.

+1 \o/

I also have trouble to distinguish between peer versus internals. I have a feeling that my code has more peers than it would be necessary.   

>>Maybe a future edition of GOOS could contain an expanded

>>discussion on this topic and more examples if this is a 

>>common point of understanding (and, judging from the interview, 

>>it may be)?

Why not a blog series? I can´t wait for the next edition of the book. :) 

Josué

@josuesantos

--

---
You received this message because you are subscribed to the Google Groups "Growing Object-Oriented Software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to growing-object-oriente...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Daniel Wellman]

Yes, thank you Philip for telling us about it and thank you Nat for what I assume was a late evening conversation. Many folks at my company in New York watched the interview with me. 

I too struggle with peers versus internals and suspect I have many peers that could probably be internals. Count me in the crowd that would find more about this subject interesting. I also have the suspicion that I could create more value objects which might help this situation as well. 

Cheers

Dan

[Matteo Vaccari]

I too struggle with peers vs internals.  Expecially after internalizing Miško Hevery advice "don't look for things, ask for things!" I tended to make everything a peer.  And yet, one of Craig Larman's GRASP patterns is "creator"

https://goo.gl/9lC9qI

where he lists a number of criteria for deciding who should create an object. I find this useful in deciding when I can avoid exposing a dependency and create an object directly.

Matteo

[Władysław Mettler]

I believe that in order to make a distinction between 'internals' and 'peers' you should turn your thinking about your code and your domain inside-out. Literally. Everything that makes decisions and is an externalization of your business logic is the 'internal'. Everything that deals with I/O, data persistence and other business logic is on the outside. I found thinking in terms of hexagonal architecture (http://alistair.cockburn.us/Hexagonal+architecture) very useful. You can use CRC cards to discover the scope of your services (http://alistair.cockburn.us/Using+CRC+cards).

A little bit more on this type of architecture and how it fits the microservices (shameless plug): https://skillsmatter.com/skillscasts/5280-hexagonal-microservices

Vlad

To unsubscribe from this group and stop receiving emails from it, send an email to growing-object-oriented-software+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

---
You received this message because you are subscribed to the Google Groups "Growing Object-Oriented Software" group.

To unsubscribe from this group and stop receiving emails from it, send an email to growing-object-oriented-software+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

---
You received this message because you are subscribed to the Google Groups "Growing Object-Oriented Software" group.

To unsubscribe from this group and stop receiving emails from it, send an email to growing-object-oriented-software+unsubscribe@googlegroups.com.

[Steven Solomon]

Vlad you bring up good points. In addition we need to correctly identify an abstraction and it's detail. Kent Beck wrote an interesting article about how different ways separating responsibilities affects the design. He asserts that we need to use how an object can be thought about in terms of it's collaborators. If it can't be reasoned about alone, its a hint that it must be folded into the object it is tightly coupled to. https://www.facebook.com/notes/kent-beck/bits-clumps-and-just-right/792597974106402

I was writing an XMLParser recently and the XML doesn't have a hierarchical structure. So, the burden of imposing that structure was put on parser. The parser has a series of book keeping objects to remember the current tag parsed and some of it's child properties still being assembled. I questioned whether to pull these book keeping objects into a ParserState object. But I decided that it was an internal. The parser's role is to marshal the data from xml into pojos and if some of that is pulled apart in an arbitrary way, it would smell. My abstraction is the XMLParser and it's detail is whatever magic needs to be done to produce my pojos. 

Thanks 

Steve

To unsubscribe from this group and stop receiving emails from it, send an email to growing-object-oriente...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

---
You received this message because you are subscribed to the Google Groups "Growing Object-Oriented Software" group.

To unsubscribe from this group and stop receiving emails from it, send an email to growing-object-oriente...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

---
You received this message because you are subscribed to the Google Groups "Growing Object-Oriented Software" group.

To unsubscribe from this group and stop receiving emails from it, send an email to growing-object-oriente...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

---
You received this message because you are subscribed to the Google Groups "Growing Object-Oriented Software" group.

To unsubscribe from this group and stop receiving emails from it, send an email to growing-object-oriente...@googlegroups.com.

[philip schwarz]

>"how to distinguish between peers and internals"

Hi Grzegorz, that brings back memories of questions I asked in what about testing dependencies are called correctly, e.g. 

"Other than by titling the section describing peer objects "Internals vs. Peers", in this chapter [ch 6] GOOS doesn't actually define what an object's Internals are (it defers this to chapter 7). Although it seems kind of obvious from the title that the Internals of an object are those collaborators that are not its Peers, I find it confusing that earlier on, Peers were defined as "the objects it communicates with directly", because that suggests that an object does not communicate with its Internals directly, but I don't understand what that means: aren't internals collaborators? Doesn't an object communicate with all collaborators in the same way: by sending them messages?"

Philip

[philip schwarz]

looking through my notes for 'peers', here are a couple of comments from Isaiah Perumalla on the Yahoo TDD Group Classic/mockist discussion (2008).

Here is the first one:

"If the tests almost mirrors code under test, its generally a test smell, it means your mocking the internals of an object not its peers. Mock objects are just a tool in your TDD toolbox, its applicable in certain contexts, so you wouldn't use it in every scenario. I wrote a blog post on some of the lessons i learnt. http://isaiahperumalla.wordpress.com/2008/04/ "

 

And here is the second one:

> 2. Peers / internals -- how do you know which is which when you design

> your system outside-in? I guess it is some kind of "feeling" - but

> could you try to describe it?

>

I found Identifying the peers and internals one of the keys to

modeling interactions between objects. The tests will quickly tell you

if the interactions are not at the right level.

for example in a previous project i worked on they had a REST service

which took in an Order XML and then did some processing to validate

the message, if the order was valid an Event was published to say the

order was accepted, otherwise an invalid order notification was sent out.

So there were three main objects here,

1) the rest service

2) order validator

3) Event publisher

The tests were using mock objects quite heavily, the tests were

verifying the interaction between all three objects which made the

tests almost mirror the implementation. The rest service could handle

the order validation itself and not delegate this to the order

validator, and as long as the correct events are published the tests

should pass, but this was not the case, refactoring was a pain because

all tests were dependent on implementation

The problem here is the order validator is an internal to the rest

service implementation not a peer and the

interaction with the order validator need not be modeled since its an

implementation detail of the rest service.

The event publisher in this case would be considered to be a peer and

interactions between rest service and event publisher should be verified.

Actually, I think Isaiah Perumalla is a member of this group. Isaiah: can you share more of your knowledge on this subject?

Philip

On Friday, 12 June 2015 11:44:43 UTC+1, Grzegorz Gałęzowski wrote:

[philip schwarz]

back in 2011, Gary Bernhardt, author of TDD, Straw Men, and Rhetoric and Test Isolation Is About Avoiding Mocks tweeted: "I'm woefully ignorant of the subtle internals/peers distinction that proper GOOSers draw. Need to fix that."

I just asked him on twitter if he can share anything on the distinction, but he has about 19K followers and is only just getting back to twitter after a long absence, so I am not holding my breath.

Philip

@garybernhardt I'm woefully ignorant of the subtle internals/peers distinction that proper GOOSers draw. Need to fix that.

On Friday, 12 June 2015 11:44:43 UTC+1, Grzegorz Gałęzowski wrote:

[philip schwarz]

I asked Isaiah Perumalla if he could share other writings on the subject of peers versus internals.

Here is a recap of the links we have so far:

• Test Driven Design using mocks – Lessons learnt (Part 1) https://isaiahperumalla.wordpress.com/2008/04/ 
  
• Test Driven Design using mocks- Lessons Learnt (Part 2) https://isaiahperumalla.wordpress.com/2008/05/28/test-driven-design-using-mocks-lessons-learnt-part-2/
  
• Using Mocks And Tests To Design Role-Based Objects https://msdn.microsoft.com/en-ca/magazine/dd882516.aspx
  
• Designing inter-object protocols using mocks https://isaiahperumalla.wordpress.com/2009/06/08/designing-inter-object-protocols-using-mocks/

Philip

[Grzegorz Gałęzowski]

Philip, I looked again at the source code of GOOS long example, hunting for objects that are not passed from the outside, but rather created by or maintained completely by other classes.

Here is what I found after rejecting the XMPP layer (which is almost exclusively driven by integration/acceptance tests) and GUI:

Announcer - a utility for raising events, mainly a compensation for a missing language feature

ArrayList - just a collection maintained internally - such objects is obvious candidates for internals

AuctionSniper - created inline in sniper launcher - can it be considered an internal?

Apart from that, the rest of the internals are values or enums (which I think are values anyway) or exceptions, which all are obviously not to be mocked.

Any observations or thoughts on this?

grzesiek