Re: [GOOS] Presenter-first design

[Uberto Barbini]

I think you can start wherever you like as far as you keep the
skeleton walking and the tests running..

Uberto

On Sat, May 4, 2013 at 5:33 AM, Johnny Smith <johnny.s...@gmail.com> wrote:
> The GOOS book teaches me to start my software from the walking skeleton,
> making sure that we can deploy our software on day one. What are your
> thoughts about presenter-first design? I think that's a good approach too,
> starting from the top layer and work your way until you touch the system.
>
> --
>
> ---
> 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/groups/opt_out.
>
>

[Nat Pryce]

On 4 May 2013 05:33, Johnny Smith <johnny.s...@gmail.com> wrote:

The GOOS book teaches me to start my software from the walking skeleton, making sure that we can deploy our software on day one. What are your thoughts about presenter-first design? I think that's a good approach too, starting from the top layer and work your way until you touch the system.

I find it useful to start from the inputs to my system and work through to the outputs, adding a  functionality to a thin slice of the system bit by bit.  I find this ensures the code only has functionality that is needed -- no "just in case" code -- and the domain model works well with the technical infrastructure it sits in -- no awkward or inefficient code adapting the abstractions in the domain model to the realities of the technical infrastructure.

If the system has a GUI I would write a bit of GUI (or code just behind the GUI) that can accept input, feed it into the domain model, adding controllers (in MVC speak) and domain model code as required, and then work back to the GUI to display any output.

So I think that way of working fits quite well with the "presenter first" idea, although maybe its more "presenter first and last".

 

Cheers,

    --Nat

--
http://www.natpryce.com

[Gishu Pillai]

Presenter first IMHO is a way of designing your system so that you can test without the GUI, which I think everyone (more or less) agrees is a good idea.

The reason with starting with the GUI vs the Presenter (or any other inner layer) is outside-in generally results in less rework and usable interfaces. When you design outside-in, your interfaces are in terms of the client and there is less probability of misunderstanding between the caller and the callee.

e.g. GUI > Presenter > Services > Repositories

Starting with the needs of the real GUI helps drive the design of the Presenter which I find useful (The same principle behind tests driving the design of the code).

If you're good with determining the Presenter interface without having the construct a real (though rough) GUI, you could succeed. In my experience, inside-out design results in the tail wagging the dog (e.g. see the client having to jump through hoops to get a simple task done because the callee has been designed for flexibility / [insert unsubstantiated future benefit here] ).

-- Gishu

[Johnny Smith]

Hi Gishu and Nat,

I design from the presenter first, then quickly implement the view once the presenter is stable. I do this because the complex of my GUI; mobile apps nowadays have complex GUIs. I can make a simpler GUI first and do the testing, but as the GUI becomes more complex, it's painful to do the testing from the inputs. Yes this approach is prone to 'just in case' code, but I can't seem to find a better way. I prefer to start from the inputs if the GUI is simple though. Any advice on how to do it?

-- Johnny

[Ilmari Vacklin]

On 8.5.2013, at 19.48, Johnny Smith <johnny.s...@gmail.com> wrote:
> as the GUI becomes more complex, it's painful to do the testing from the inputs.

What makes testing from inputs painful? It is my experience that if the UI is hard to test it is hard to use as well.

I've found that there is often unneeded complexity in the UI that is reflected to the code, and vice versa.

[Gishu Pillai]

Don't get me wrong, at the system level, I prefer writing more tests at the presenter boundary than at the GUI level. The whole point of Presenter first is to enable testing.

My suggestion is to start with the UX / Mock screens so that you get (derive) the Presenter public interface right the first time.

You should have a few GUI Tests that verify that everything is wired up correctly - so it might be worth investigating for some tools that enable this. (e.g. desktop  => TestStack.White, Web => Selenium, etc.)

[Johnny Smith]

On Thursday, May 9, 2013 12:14:05 AM UTC+7, Ilmari Vacklin wrote:

On 8.5.2013, at 19.48, Johnny Smith <johnny.s...@gmail.com> wrote: 

> as the GUI becomes more complex, it's painful to do the testing from the inputs. 

What makes testing from inputs painful? It is my experience that if the UI is hard to test it is hard to use as well. 

I've found that there is often unneeded complexity in the UI that is reflected to the code, and vice versa.

If the input(UI events) you mean is the same when I'm writing the post, I just find it tedious searching for components in relatively deep UI tree, simulating events especially gesture events in mobile applications. It is difficult, not that the UI is hard to use, but placing components in proper place is not that easy.

So the key is to start at the outermost layer as possible right? If starting from GUI is difficult, at least I have to start from the code behind the GUI just like Nat said.

By the way, why the MVP/MVC pattern is never stated explicitly in the book? Is it because the pattern will naturally exist as the code base grows? If my understanding is correct, then is it true that the AuctionSniper is the presenter and the SniperListener is the view?

[Torbjörn Kalin]

For me, presenter-first is a tool for testing/designing presentation logic (as opposed to e.g. business logic or persistence logic). It means that, when you write tests for the UI, start with the presenter.

In trivial applications, with a simple domain, you could probably use it to drive the design of the whole application (as mentioned by others in the thread). But if the domain is more complex you probably want to put more focus on the business logic. To find the seams between different kinds of logic, to discover what part of the code the business logic tests should interact with, the walking skeleton is an excellent tool.

Presenter-first is of course not the only available TDD tool for designing the presentation logic. Personally, I think it's a bit "narrow" in the sense that the tests exercise a too small part of the system. If you discover that some logic that you put in the presenter ought to be elsewhere, it is quite difficult to move it since the tests lock it in. For instance, I have discovered a need to sometimes extract a controller from the presenter (that is, the presenter updates the view while the controller reacts to user interaction), something that is difficult when using presenter-first. So I prefer including the shower and the model in the presentation logic tests (shower-first?).

/T

On Sat, May 4, 2013 at 6:33 AM, Johnny Smith <johnny.s...@gmail.com> wrote:

The GOOS book teaches me to start my software from the walking skeleton, making sure that we can deploy our software on day one. What are your thoughts about presenter-first design? I think that's a good approach too, starting from the top layer and work your way until you touch the system.

--

[Gishu Pillai]

So the key is to start at the outermost layer as possible right? If starting from GUI is difficult, at least I have to start from the code behind the GUI just like Nat said.

 Yes. Just begin with the UX in mind... You don't want to end up with a presenter that won't 'fit' with the view.

 

By the way, why the MVP/MVC pattern is never stated explicitly in the book? Is it because the pattern will naturally exist as the code base grows? If my understanding is correct, then is it true that the AuctionSniper is the presenter and the SniperListener is the view?

 I read it a while back and don't have the book at hand.. The Presenter is always the class that the UI 'binds' its data fields to. 

[Rick Pingry]

I have been working on trying to get TDD in to my head for a few years now, and I keep bouncing off it and getting frustrated.  A few months ago I started a new project in Java (Most of my career has been as a C++ applications developer).  A new project was a great place to start with Walking Skeleton and end-to-end tests goos style.  I even used Window Licker.  After a bit of playing around with that, I switched to using JavaFX and Jemmy-FX, wick I liked lot better (sorry guys, it seemed window licker was a bit abandoned).

After getting quite a ways into things, I noticed that I was having many times more gui/accepteance tests with jemmy-fx than I had unit tests, and I realized I was doing things wrong yet again (I don't know why this is so hard for me to get right).

Then our team decided to try a Presenter first kind of methodology and even named things XPresenter, XController (Controller already has a meaning in JavaFX, I can't really create it and use it outside of the GUI and test it independently, so it is really more like a View), sometimes even an XModel.  We gave ourselves very strict rules about what each class was allowed to do, and all of the sudden, our ability to write tests absolutely blossomed!  I know I am probably still doing something wrong (you guys probably HATE the naming paradigm, but I think I need it as training wheels to really hammer in the kinds of responsibilities I need), but I am including this in this thread for all of the thick headed people like me that struggle over and over again with TDD,  Having a very specific way of thinking about responsibilities REALLY helped me.

I think my next step is to learn again how to write Acceptance Tests, more accurately when (or when NOT) to write acceptance tests.  When I did write them, I had a hard time making the transition to writing the unit tests.  still learning :)

[Nat Pryce]

On 11 May 2013 05:08, Rick Pingry <rpi...@gmail.com> wrote:

I even used Window Licker.  After a bit of playing around with that, I switched to using JavaFX and Jemmy-FX, wick I liked lot better (sorry guys, it seemed window licker was a bit abandoned).

That's cool.  When we wrote WindowLicker, the similar libraries out there were either commercial, or had a dreadful API that would have got in the way of explaining what was going on, or both!.  These days there are better open-source alternatives. And if you're not writing a book the API quality issue is probably not a problem -- you can wrap it in some syntactic sugar and don't have to write pages of explanation as to what it does and why.

--Nat

--
http://www.natpryce.com

[Johnny Smith]

Nice advice Rick, thanks :)

So what did you do with your acceptance tests after that? Do you build the walking skeleton when using presenter-first design?

[Rick Pingry]

So what did you do with your acceptance tests after that? Do you build the walking skeleton when using presenter-first design?

When I started this project, I focused so much on the Walking Skeleton that I totally did not get into doing the Unit tests hardly at all.  I always felt that my acceptance tests were covering what I needed them to, so it felt dumb to then write a unit test as well.  I ended up essentially writing EVERYTHING from the acceptance test point, which was once again WRONG!  I ended up having lots and lots of tests at this level (with wonderful coverage).  As you can imagine, they soon became cumbersome and brittle.  They were also not helping me much in the way of design.  They also take a huge amount of work.  I was spending much more time writing and fixing tests than I was writing production code.  We did NOT have the presenter mechanisms in place at this point.

So I took a big step back.  (I should say here that I am very lucky right now to be working on a project where part of the whole goal is to be working on a test driven process as well as getting actual code out, so my client's are very patient with my fumbling around).

This time I wanted to focus purely on unit tests, or what we like to call "class isolation tests" (testing a single class and mocking all collaborators) because the word Unit is defined  so differently by different people.  This time, we made our acceptance tests purely manual tests, and we are not concerned with running them after we finish the unit, so they don't help much for regression.  Our particular application is really easy to deploy and run, and I knew that I would always be running the app to see if I actually did what I set out to do anyway.  I knew I would do that regardless of the acceptance tests anyway, and I had such a bad taste in my mouth from the acceptance tests, that I needed a break from them.

So, that is where we are now.  To answer your question then, No, no acceptance tests using the Presenter paradigm, but I know that is not quite right either.  I need to slide back into doing them again at some level, but I am not sure how, so I could use some help from someone with ideas.  When reading the GOOS book, I have a hard time seeing and understanding the transition between writing the acceptance tests and then dropping down to write the unit tests.

I could make it so every change in the code starts with an acceptance test and then drop down to writing unit tests, but that got me where I was before.  It was said there should be far fewer acceptance tests than unit tests.  So, when do you write an acceptance test first and when do you not?

I have been toying around with the idea of writing "Integration" tests that only mock the view/controller boundaries and starting everything with a test from there that is really the user story, and then drop down through each layer of the application, writing isolation tests as I go.  It seems that this route would provide fast tests that are not so brittle, and I could have more confidence in them from a regression stand-point (since they do cover several layers at once and their integration)  JBrains (from what I understand) seems to not like any level of integration tests, and makes me believe that my isolation tests are sufficient.  

One thing that my clients really like is watching the end-to-end tests play.  In particular, we are writing what we call "Tutorial Tests".  We automate using the software for something significant the end user would want to do, perhaps something that is in the user's manual.  We actually slow the tests down a little so a human watching can see the interactions.  We don't even really need to check for much in the tests, because if we actually see the test run then we are pretty confident that everything is ok.  This would certainly show that the system is together and is a rather beefy "Walking Skeleton".  Perhaps that would suffice as a walking skeleton tests to really prove the entire app is working, but then have integration tests for each interaction in the user story, which serve as great regression tests, then isolation tests at each layer in the code...  Ideas anyone?  Am I heading in the right direction?

[Colin Vipurs]

This time I wanted to focus purely on unit tests, or what we like to call "class isolation tests" (testing a single class and mocking all collaborators) because the word Unit is defined  so differently by different people. 

The phrase "unit test" has become massive overloaded, something I've seen get worse as the years go on and more people do it (I once saw a test launch MS Word and the developer still insisted it was a "unit" test).  Rather than rename them, I fight tooth and nail with everyone I meet that misuses the phrase and try to educate them as to what a "unit" test really is. 

[Rick Pingry]

yeah, I think it is just because the term "Unit" is suspect.  Unit is such a vague word that implies different things in different contexts.  That is a tough battle to wage, but I understand the need to have a common vernacular.

Who is it that defines what a "Unit Test" really means?  Is there a standards committee?

[Steve Freeman]

Apparently Google talk in terms of Small (isolated, very fast), Medium (integration, touches some external resources), and Large (system-level). 

S. 

Sent from a device without a keyboard. Please excuse brevity, errors, and embarrassing autocorrections. 

--

[David Peterson]

I think it's important to keep a distinction between acceptance tests and end-to-end tests. Although acceptance tests are often written as end-to-end tests, there is nothing that says they have to be. If you write your acceptance test to express the intention rather than the implementation, you can often hook them in at a inner level - even down to testing a single class. Those kinds of acceptance tests run super-fast and if you need to redesign the class you can hook the test so it runs at a wider level (e.g. module or end-to-end level) then when you refactor you are protected by tests.

David

On Monday, May 13, 2013 5:14:42 PM UTC+1, Rick Pingry wrote:

When I started this project, I focused so much on the Walking Skeleton that I totally did not get into doing the Unit tests hardly at all.  I always felt that my acceptance tests were covering what I needed them to, so it felt dumb to then write a unit test as well.  I ended up essentially writing EVERYTHING from the acceptance test point, which was once again WRONG!  I ended up having lots and lots of tests at this level (with wonderful coverage).  As you can imagine, they soon became cumbersome and brittle.  They were also not helping me much in the way of design.  They also take a huge amount of work.  I was spending much more time writing and fixing tests than I was writing production code.  We did NOT have the presenter mechanisms in place at this point.

...

[Colin Vipurs]

Agreed.  We do redefine some of the phrases according to what they mean to us, e.g. "acceptance test" to us means something different to a different company.  As long as the terminology is understood across a company then it's ok, "unit test" is just a personal bug bear to me.  Back when I started doing automated testing at the turn of the century it was a fairly well defined term, I'm guessing because not huge amount of people were doing it.  As time went on and it became more popular I saw the usage being diluted to mean anything from an honest unit test to any automated test and to (usually non-developers) any kind of test, automated or not.

Like I said, it's more of a personal thing and more than likely my OCD about it.

--

 
---
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/groups/opt_out.
 
 

--
Maybe she awoke to see the roommate's boyfriend swinging from the chandelier wearing a boar's head.

Something which you, I, and everyone else would call "Tuesday", of course.

[Matt Wynne]

On 16 May 2013, at 11:40, David Peterson <da...@crowdsoft.com> wrote:

I think it's important to keep a distinction between acceptance tests and end-to-end tests. Although acceptance tests are often written as end-to-end tests, there is nothing that says they have to be. If you write your acceptance test to express the intention rather than the implementation, you can often hook them in at a inner level - even down to testing a single class. Those kinds of acceptance tests run super-fast and if you need to redesign the class you can hook the test so it runs at a wider level (e.g. module or end-to-end level) then when you refactor you are protected by tests.

YES!

http://claysnow.co.uk/?p=175315341

David

On Monday, May 13, 2013 5:14:42 PM UTC+1, Rick Pingry wrote:

When I started this project, I focused so much on the Walking Skeleton that I totally did not get into doing the Unit tests hardly at all.  I always felt that my acceptance tests were covering what I needed them to, so it felt dumb to then write a unit test as well.  I ended up essentially writing EVERYTHING from the acceptance test point, which was once again WRONG!  I ended up having lots and lots of tests at this level (with wonderful coverage).  As you can imagine, they soon became cumbersome and brittle.  They were also not helping me much in the way of design.  They also take a huge amount of work.  I was spending much more time writing and fixing tests than I was writing production code.  We did NOT have the presenter mechanisms in place at this point.

...

--
 
---
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/groups/opt_out.
 
 

cheers,

Matt

--
http://mattwynne.net || https://twitter.com/mattwynne || http://the-cucumber-book.com || http://bddkickstart.com || http://www.relishapp.com

[David Peterson]

I've noticed my definition of unit tests has evolved along the same lines as the launching MS Word example and I don't actually see it as a bad thing. I used to think and talk about unit tests as being tests of just a single class with mocked/stubbed dependencies. Now I find it more useful to think fractally with units as being at any level - class, module, system. They are all units.

If I want to distinguish, I'd talk about class-tests, testing clusters of classes, module tests, system tests, but maybe "small", "medium", "large" is simpler or maybe "fast", "medium", "slow" is even more useful?

David

--
 
---
You received this message because you are subscribed to a topic in the Google Groups "Growing Object-Oriented Software" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/growing-object-oriented-software/H6tNVvNCFYM/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to growing-object-oriente...@googlegroups.com.

[Johnny Smith]

I think I need some help too. After reading the book, I think that acceptance tests exist only to tell us whether a feature is complete, but how much is a feature?

If I have a form that has 10 fields to be validated before submitting, do I have to write at least 11 acceptance tests? 1 for each invalid fields and 1 for a success case. As confused as Rick do, when is not the correct time to write acceptance tests? Do I have to write 2(failed and successful login) tests for a login scenario?

[Torbjörn Kalin]

Rick: A late reply to your comments on that you will focus on "class isolation tests" over "acceptance tests":

I see your point and sort of agree with you. But I have a few buts.

I find one of the most important principles when writing a test is to test against a stable boundaries/interfaces. Whenever I write a test, I ask myself if the interfaces it's interacting with is something I expect to be around for a long time.

There are two way to handle a test that is interacting with a "bad" boundary. One is to change the test. When doing this, chances are that the production code must change at the same. That's bad, and quite a tedious work to do. But the second option is even worse: to live with the bad boundary, and to live with a sub-optimal design.

Since, to begin with, there are no boundaries, I usually start testing at the outer level of the system (perhaps including the database, depending on what kind of system it is). In the beginning, there's no problem testing at this level. But after a while it might become troublesome, just like you noticed. And that's when it's time to start looking for those boundaries. Now I can rewrite my tests (without changing the production code) to interact with a more appropriate level. And changing the test from facing one stable boundary to facing another is quite easy most of the time. And after a while, the same thing happens again: the new boundary becomes troublesome to work with, so I rewrite the test again to interact with an even smaller part. And so on.

Finally, I end up with tests that only interact with one or a few classes. But I know that it's the right classes, classes that I have discovered through refactorings, supported by tests, not classes that I invented up front.

(Disclaimer: This, of course, doesn't apply to all systems and all situations. Context is everything.)

/T

--

[Steve Freeman]

It all depends :) but I might write a couple of large scale tests to show the general flow (1 success case and 1 failure case), and then some more focussed tests for the validations. It would only make sense to write all the detailed tests at the outside if there were no other way to do it and I could make them run very quickly.

S

[Josue Barbosa dos Santos]

On Thu, May 16, 2013 at 2:12 PM, Johnny Smith <johnny.s...@gmail.com> wrote:

I think I need some help too. After reading the book, I think that acceptance tests exist only to tell us whether a feature is complete, but how much is a feature?

If I have a form that has 10 fields to be validated before submitting, do I have to write at least 11 acceptance tests? 1 for each invalid fields and 1 for a success case. As confused as Rick do, when is not the correct time to write acceptance tests? Do I have to write 2(failed and successful login) tests for a login scenario?

Hello Johnny,

I will try to explain how we do in my Job. We use ATDD + TDD. So to write any code you need a failing acceptance test that was validated by the business. So in your example, yes we write the 11 acceptance tests (ATs). The ATs serve to us as DOCUMENTATION too. I think the documentation part of the ATs sometimes is forgotten. Example, suppose a form with three required fields: name;  age; address. Probably we would have 4 acceptance tests (pseudo java):

public void shouldInsertWithSucess(){

    assertApplicationMessage("Inserted with success", VALID_NAME, VALID_AGE, VALID_ADDRESS);

} 

public void nameShouldBeRequired(){

    assertApplicationMessage("Name is required", "", VALID_AGE, VALID_ADDRESS);

}

public void ageShouldBeRequired(){

    assertApplicationMessage("Age is required", VALID_NAME, "", VALID_ADDRESS);

}

public void adressShouldBeRequired(){

    assertApplicationMessage("Address is required", VALID_NAME, VALID_AGE, "");

}

public void assertApplicationMessage(String expectedMessage, String name, String age, String address){

    assertEquals(expectedMessage, application.insert(name, age, address); 

}

If i did the first test to do the others is very easy. In this example is almost copy and past. What is the problem to write all the acceptance tests? As I said the ATs serve us as documentation.  When we want to know what the system does we look to the ATs. As our systems are web systems, one possible problem is performance when testing from the web interface and there lots of tests. To resolve it the application object used in the example has two implementations. One that exercised the fully application deployed throw the web interface (using selenium and webdriver), and other that uses the layer behind the ui (we named it direct calls acceptance tests). We steal this idea from the book "Testing Extreme Programming" by Lisa Crispin.

As they are slower the execution of all web tests happens more in CI. In the daily work the developers use more the direct calls acceptance tests.

As English is not my main language sorry for any no clear points.

-- 
Abraços,
Josué
http://twitter.com/josuesantos

 

On Monday, May 13, 2013 11:14:42 PM UTC+7, Rick Pingry wrote:

So what did you do with your acceptance tests after that? Do you build the walking skeleton when using presenter-first design?

When I started this project, I focused so much on the Walking Skeleton that I totally did not get into doing the Unit tests hardly at all.  I always felt that my acceptance tests were covering what I needed them to, so it felt dumb to then write a unit test as well.  I ended up essentially writing EVERYTHING from the acceptance test point, which was once again WRONG!  I ended up having lots and lots of tests at this level (with wonderful coverage).  As you can imagine, they soon became cumbersome and brittle.  They were also not helping me much in the way of design.  They also take a huge amount of work.  I was spending much more time writing and fixing tests than I was writing production code.  We did NOT have the presenter mechanisms in place at this point.

So I took a big step back.  (I should say here that I am very lucky right now to be working on a project where part of the whole goal is to be working on a test driven process as well as getting actual code out, so my client's are very patient with my fumbling around).

This time I wanted to focus purely on unit tests, or what we like to call "class isolation tests" (testing a single class and mocking all collaborators) because the word Unit is defined  so differently by different people.  This time, we made our acceptance tests purely manual tests, and we are not concerned with running them after we finish the unit, so they don't help much for regression.  Our particular application is really easy to deploy and run, and I knew that I would always be running the app to see if I actually did what I set out to do anyway.  I knew I would do that regardless of the acceptance tests anyway, and I had such a bad taste in my mouth from the acceptance tests, that I needed a break from them.

So, that is where we are now.  To answer your question then, No, no acceptance tests using the Presenter paradigm, but I know that is not quite right either.  I need to slide back into doing them again at some level, but I am not sure how, so I could use some help from someone with ideas.  When reading the GOOS book, I have a hard time seeing and understanding the transition between writing the acceptance tests and then dropping down to write the unit tests.

I could make it so every change in the code starts with an acceptance test and then drop down to writing unit tests, but that got me where I was before.  It was said there should be far fewer acceptance tests than unit tests.  So, when do you write an acceptance test first and when do you not?

I have been toying around with the idea of writing "Integration" tests that only mock the view/controller boundaries and starting everything with a test from there that is really the user story, and then drop down through each layer of the application, writing isolation tests as I go.  It seems that this route would provide fast tests that are not so brittle, and I could have more confidence in them from a regression stand-point (since they do cover several layers at once and their integration)  JBrains (from what I understand) seems to not like any level of integration tests, and makes me believe that my isolation tests are sufficient.  

One thing that my clients really like is watching the end-to-end tests play.  In particular, we are writing what we call "Tutorial Tests".  We automate using the software for something significant the end user would want to do, perhaps something that is in the user's manual.  We actually slow the tests down a little so a human watching can see the interactions.  We don't even really need to check for much in the tests, because if we actually see the test run then we are pretty confident that everything is ok.  This would certainly show that the system is together and is a rather beefy "Walking Skeleton".  Perhaps that would suffice as a walking skeleton tests to really prove the entire app is working, but then have integration tests for each interaction in the user story, which serve as great regression tests, then isolation tests at each layer in the code...  Ideas anyone?  Am I heading in the right direction?

--

[Rick Pingry]

Thanks Tor and Josué,

I really liked what you had to say.  I also liked your statements on the other thread about why, what, and how being more important than the terminology.

When I first read what you wrote above, about only testing against stable interfaces, my head did begin to spin a little.  In one respect, I totally have had the issue where I am constantly changing interfaces I have to thrash between implementations and tests and I hate that.  On the other hand, however, I thought that the purpose of TDD was to help me define those interfaces.... hmmm.  Not that I think that it must be that way, however.  I have found that I like to define the interfaces in the client that is using it, so sometimes I feel like I am doing extra work that does not really help me if I use TDD to define the interfaces (usually after the fact).

I do think it is kind of neat that you have the tests define when it is time for you to move down a little.  The pain of the tests (listening to the tests) tell you when you are ready to move to a lower level boundary.

I am a little un-clear on the process, however.  You start the tests on the outer, more solidified interfaces and then move down.

- Do you always re-write the tests at the appropriate levels after the class is solidified?  

- If you didn't, it seems you would have tests that exercise a certain class, but by calling the client of the class rather than the class itself, right?  Is that ok?

- Then when you do move down, and if you don't re-write the tests, then you would have some tests on a class that are exercised by calling the client of the class and some others by calling the class itself.

- IF you do re-write the tests, which it seems like you must, then you must be writing tests on code that is already working.  Does the act if re-writing a test seem like a chore?

Thanks Again,

-- Rick

[Johnny Smith]

Thank you for your replies Steve and Josué.

Looks like it's a matter of skill and experience to decide which acceptance test to write. If that's so, then I have to practice much more to decide when is the right time to write acceptance tests when it's too much.

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

[Rick Pingry]

So, Josué,

How do you like to organize your AT's so that they serve the best as documentation?  It seems that they aren't really organized by classes.  Perhaps they are organized by user stories or by interface screens or features or something like that?

-- Rick

[Torbjörn Kalin]

Good questions :)

The first days or even weeks on a greenfield project I probably spend as much time refactoring the code as I do implementing new behavior. And I probably spend as much time refactoring the tests as I do refactoring the production code. The test code is no second class citizen but requires as much love as the production code.

Also, I usually create an "automation layer", code that separates the tests from the production code. If you've used BDD tools such as SpecFlow or JBehave this should be familiar. But I do this also when the tests are written in the same language as the production code for (at least) two reasons:

One is to enhance readability. I want the code in a test to be all about behavior, and I want it to contain only things that are important for what the test verifies. For instance, you'd typically don't find mock framework code in my test method since that's an implementation detail.

The second reason, and the reason that is important for your questions, is that the automation layer decouples the test from the production code. The test describes the behavior that I want to verify while the automation layer keeps track of how it is verified. When I discover that I'm testing at the wrong level, I typically only have to change the automation layer, while the test methods remain unchanged. Since the automation layer is reused by many tests, the change is typically quite easy to do.

This automation layer is not something I create up-front, but rather something I discover and that is created through refactorings.

/T

--

[Josue Barbosa dos Santos]

Hello Rick,

Sorry for the delay (weekend and a bit busy here). The projects are organized more or less like this (Pseudo Java):

As I said we have two types of Acceptance Tests (direct calls and the web). So we have one class to each type:

@RunWith(Suite.class)

@Suite.SuiteClasses((

    UseCaseTests.class

))

public void DirectCallTests{

}

----

@RunWith(Suite.class)

@Suite.SuiteClasses((

    UseCaseTests.class

))

public void WebTests{

}

The UseCaseTests groups the tests to all use cases:

@RunWith(Suite.class)

@Suite.SuiteClasses((

    CreatesAccountUseCaseTest.class,

    PurchasesItemUseCaseTest.class,

    ShipsItemUseCaseTest.class

))

public void UseCaseTests{

}

And one use case is composed from one or more stories:

@RunWith(Suite.class)

@Suite.SuiteClasses((

    CreateSimpleAccountStoryTest.class,

    CreateAdministrativeAccountStoryTest.class,

    StrongPasswordStoryTest.class

))

public void CreatesAccountUseCaseTest{

}

And the story has the tests. As we use BDD the story test is, generally, composed of Givens classes:

@RunWith(Suite.class)

@Suite.SuiteClasses((

    GivenTheLogedUserIsSuperUser.class,

    GivenTheLogedUserIsNormalUser.class

))

public void CreateSimpleAccountStoryTest{

}

And the Givens has the tests:

...

public void GivenTheLogedUserIsSuperUser {

    public void shouldBeAbleToCreateSimpleAcount(){

    //your test code here

    }

}

....

public void GivenTheLogedUserIsNormalUser{

    public void shouldNotBeAbleToCreateSimpleAcount(){

    //your test code here

    }

}

And that is it. It is in our todo list study the possibility to change this strategy to use other tools like JBehave or Cucumber o even a better structure in the code. But as it working for us today, it is not high priority.

Hope that helps.

-- 
Abraços,
Josué
http://twitter.com/josuesantos

-- Rick

--

[Rick Pingry]

That is way cool, Josué.  So you keep the one set of AT's running fast for the developers to run often, and allow the slow ones that actually hit the web boundary to run on your build server.  But I guess the key thing there is to avoid duplication across those 2 environments so that really both are running the same set of tests.

So, at the top level, it is the DirectCallTests and the WebTests functions that set up the environment either way? I have never used JUnit's @RunWith(Suite.class)

@Suite.SuiteClasses functionality, so I have a little homeowrk to do :)

I also really like how you have broken things up into User Stories -> Givens -> Expectations (the final test functions).

One last question, do you have AT's along every logical boundary?  If you know you need to make some kind of check somewhere, do you always write an AT first, and then a Unit test down where the check actually happens?  If not, how do you decide whether to do it or not? 

[Josue Barbosa dos Santos]

On Tue, May 21, 2013 at 1:33 PM, Rick Pingry <rpi...@gmail.com> wrote:

So, at the top level, it is the DirectCallTests and the WebTests functions that set up the environment either way? 

Yes.

 

One last question, do you have AT's along every logical boundary?  If you know you need to make some kind of check somewhere, do you always write an AT first, and then a Unit test down where the check actually happens?  If not, how do you decide whether to do it or not? 

Yes. The "some kind of check somewhere" need to be justified by at least one AT. and this one AT imply in one or more unit tests. The ATs always guide what has to be done.

--

 
---
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/groups/opt_out.
 
 

[Rick Pingry]

>> Yes. The "some kind of check somewhere" need to be justified by at least one AT. and this one AT imply in one or more unit tests. The ATs always guide what has to be done.

What you are saying really resonates with me, thanks so much for your ideas.

So, have you ever had a time where you were tempted to JUST write the AT's, and NOT tests lower down?  Do you still feel like the Unit tests have their own value to make them worth it?  The AT's certainly have more ability to handle regression failures.  I know that the real selling point of Unit Tests is their ability to drive design.  I don't know that I have completely bought into the idea yet, so I am still struggling.

I guess my question come to this...

When you know that you have an acceptance test covering the code, does that affect when you make a decision to write a unit test or not?  I am trying to resolve "too simple to test" with "never write a line of code without a failing unit test".

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/groups/opt_out.
 
 

[Steve Freeman]

Sent from a device without a keyboard. Please excuse brevity, errors, and embarrassing autocorrections. 

On 23 May 2013, at 00:45, Rick Pingry <rpi...@gmail.com> wrote:

>> Yes. The "some kind of check somewhere" need to be justified by at least one AT. and this one AT imply in one or more unit tests. The ATs always guide what has to be done.

What you are saying really resonates with me, thanks so much for your ideas.

So, have you ever had a time where you were tempted to JUST write the AT's, and NOT tests lower down?  Do you still feel like the Unit tests have their own value to make them worth it?  The AT's certainly have more ability to handle regression failures.  I know that the real selling point of Unit Tests is their ability to drive design.  I don't know that I have completely bought into the idea yet, so I am still struggling.

There is a school of thought that prefers to write just system tests. My view is that different tests serve different purposes, especially when we're using tests to help us think about design. So small scale tests help me maintain the internal quality of the system. In practice I find these days that my unit tests tend to cover small clusters rather than individual objects.

I guess my question come to this...

When you know that you have an acceptance test covering the code, does that affect when you make a decision to write a unit test or not?  I am trying to resolve "too simple to test" with "never write a line of code without a failing unit test".

I think that's without a failing test, not necessarily unit. The trick is to overdo it so you know where the boundaries are.

S. 

[Ben Biddington]

So're you verifying the intra-cluster communications at all? Or just inter-?

--

 
---
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.

[David Peterson]

And if the latter, does it suggest a missing abstraction?

You received this message because you are subscribed to a topic in the Google Groups "Growing Object-Oriented Software" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/growing-object-oriented-software/H6tNVvNCFYM/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to growing-object-oriente...@googlegroups.com.

[Josue Barbosa dos Santos]

On Wed, May 22, 2013 at 6:45 PM, Rick Pingry <rpi...@gmail.com> wrote:

>>So, have you ever had a time where you were tempted to JUST write the AT's, and NOT tests lower down?

...

>>When you know that you have an acceptance test covering the code, does that affect when you make a decision to write a unit test or not?

No. When I write one AT I always want to write the unit tests too. But there was rare cases were we do not follow this rule. Follows one case I am remembering:

In some systems we used GWT and DTOs to transfer data between the browser and the server. And we need to copy the data from DTO to server side classes (Entities). To do this we created converters and its respective unit testes. Example: ClientDTO, Client, ClientConverter, ClientConverterTests. Each new converter has its unit tests.

As the DTOs and Entities in many cases had properties with the same names, we created a generic converter with, of course, unit tests. We could create unit tests to prove that the conversion was possible. The only way that the conversion will not work is when the properties names did not match, for example, DTO has getName() and ENTITY has setNname(). For this case, the team judged that the risk of this kind of error was very low and, if it happens, the AT would take it.

Even in this case, if it was decided to create the tests, it would be no problem. It would serve as a unit test documentation of the dependency between the DTO and the Entity.

>>Do you still feel like the Unit tests have their own value to make them worth it?

Yes. Mainly to design. May be you are a good programmer and you can test drive only using ATs and keep the design nice. Maybe I could also. I don´t know I never did the experience. But with beginners to intermediate experienced developers I do not have doubt that it helps a lot. I coach and help teams in my company in this area and always some came to me and ask: "I think this test is not good. What do you think about". And generally we change the design (break a big class in smaller ones(SRP), eliminate duplication etc.) to what we think is a better design. The pain in the unit test is an indication of bad design. I think the GOOS book talk with much more details about it. :)

Others advantages related to unit testing:

FAST FEEDBACK

If you use only ATs to develop you will stay with a red (broken) test for a bigger time than if you test each class in isolation. I think I would not like this kind of development: red code refactor; red  code refactor; red code refactor...green.  I think it is more pleasurable something like: red green refactor; red green refactor; ...green. The TDD mantra. I have fun with it. Each little green is a fast feedback of progress. And it is good.

FAST FEEDBACK II

Not everyone will create ATs to run as fast as the unit tests. In this case the unit tests are essential. For example there is a system here where the direct calls tests uses the real database. This tests executes in ten minutes. The web tests in 2 hours. And the unit tests in less than 5s. 

DESIGN(again)

Note everyone will create two kinds of ATs as we do. In many projects they only automate AT at the external interface(Web for example). In this case the rule to create unit tests to every code helps inexperienced developers to not put logic in the interface component. It happened here: "How I would test it if it is in the interface and I cant instantiate the interface?". Answer: "Extract all the logic and code as possible from the view. Use, for example the presenter pattern. Hey, what this sql code is doing here?! Have you ever heard about repositories or DAOs?"

FASTER PROBLEM DETECTION

If you are creating isolated unit testing ala GOOS (interactive tests) then when your build breaks there was, theoretically, only one (or few ones) tests in red state indicating very precisely the error origin. If you use only ATs all the stack of objects used can be a potential candidate to the problem. When you work alone it is not a big problem, as probably the last updated place is the place of the error, but when you work on a team it starts to make difference.

DEFECT PREVENTION

"The act of “designing test” rather than the act of testing (i.e. knowing what to test and how to test) is one of the best known defect preventers[33]. Well I am not so smart to state this, this statement is here:

"Analysis and Quantification of Test Driven Development Approach - Boby George 

A thesis submitted to the Graduate Faculty of North Carolina State University

in partial fulfillment of the requirements for the Degree of Master of Science"

and [33]: Beizer, B., Software Testing Techniques. ITP, 2nd Edition. 1990.

I have a feeling that it is true. :)

DOCUMENTATION

The unit tests documents the api to each class used in the project. So if you are going to maintain a project that is new to you,  look at the unit tests to know how to use the classes. For example, when a search is made in the ClientSearcher.search(clienteId)  and there no itens what happens? It returns null? It returns an empty list? It throws an ClientNotFoundException? Look in the unit tests and discover the answer.

SIZE/COMPLEXITY METRICS

The number of unit tests can be o good indicator of the size and complexity of an application. Suppose an application with no restriction of time to do a client search:

Story: Search for one client 

Given a client with name Josué Santos is registered

When search by name for Josué Santos

Then should find the Josué Santos

And now we change the application to restrict the time to do the search(adding a new story):

Story: Search for one client must be in less than a one second

Given there are a million clients registered.

And a client with name Josué Santos is registered

When search by name for Josué Santos

Then should search in less than a second

The only new AT that is added verifies the time that takes to finish the search. But probably much more unit tests is created to build the solution. If you will use cache in the client side you will have unit tests do this client side code. If you also will write caching in the server side you will have unit tests to this too. So using only ATs to measure the size/complexity of an application I think is not a good idea. See more about this metrics using ATs e UTs in this paper(Agile Metrics at the Israeli Air Force) :

http://www.davidtalby.com/papers/Agile_Metrics_AgileUnited05.pdf

Side note: Here we use function points :( to pay the outsourced development. This paper gives me an idea to perhaps change to use tests points. But it is to a future far far away. If possible.

ENABLE BETTER TEAM WORK

Suppose we are in a team focused to finish the first AT from the first story. Suppose the following stack (C is class) AT->C1->C2.  You are working in C2. If we use only the AT to drive development we are using the feedback from the error that is presented when AT is executed. But this error can change in your next update because of changes made in C1 by other team member.  And you will be distracted by a thing that is not your focus on the moment. 

Other problem. Suppose AT->C1->C2. You are working on C1 and C2 is a class that is supposed to be finished. If some change in  C2 breaks it, your work in C1 will be injured because you need C2 working properly to finish C1 as you are only using the AT as guide, and ATs needs the real classes. If we were using unit tests and mock to C2 this would not be a problem to finish C1.

ATs DON´T GUIDE DEVELOPMENT

As we are using only ATs to guide the development we will probably use the bottom-up strategy. So if C1->C2->C3 then we will build C3, then C2 and then C1. And ironically, the ATs will drive less the code than when you use unit tests ala GOSS. The first code you build (C1) is not directly related wit the AT. And so may be you are doing code that is not required by the AT. When you use need driven development (GOOS) all the code is justified in a top down way by the ATs.

I don´t know if all what I said is right. It is just what I think.

Hope that helps, good weekend. See you on Monday. :)

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