"Start Each feature with an Acceptance Test" => end-to-end ?

[Michael Azerhad]

Hello,

I'm confused about the page 39 of the book, stating this:

"We write the acceptance test using only terminology from the application's domain, not from the underlying technologies (such as databases or web servers)".

Does it mean, that after writing our very first test: Walking Skeleton, being end-to-end, we start writing each acceptance feature with mocking (database etc...)??

Acceptance of real feature shouldn't be end-to-end ?

Thus, my question is:  Is each acceptance test not end-to-end? 

For example, my walking skeleton is composed of a Selenium Test combined with Page Object pattern and testing some simple action, touching to the whole set of components I use.

Now, I want to start my real first feature. Should my first acceptance test another Selenium Test? Then writing some units-test from it, until the Selenium Test passes.  

Thanks a lot :)

Michael

[Michael Azerhad]

To be more precise, the statement only talks about "terminology". Does it mean that each acceptance feature test test is still end-to-end, but we should avoid to explicitly involve terminology of a precise technology. 

For example, page Object pattern is great, since it masks the underlying UI driver (web driver, swing driver etc...), thus, if we want to change the UI style, our acceptance test (written with Selenium for instance) would not be broken. 

[Steve Freeman]

yes. At this level, we're trying to describe what the system is for, not how it does it (or how the test is implemented). There's an additional advantage that this level of abstraction protects the tests from irrelevant changes to the system implementation.

S

[Michael Azerhad]

Your "yes" answer means well that acceptance test should be a true end-to-end test. (for confirmation)

Recently, I watched this conference from Uncle Bob, presenting his vision about a Clean Architecture:  http://www.youtube.com/watch?v=asLUTiJJqdE

According to him, starting with an end-to-end test for every acceptance feature is really not advised. Indeed, he expects developers to focus ONLY on use-cases first, with Plain Old Java Object only. Why ? Because boundaries (web server, database, mail server, XMPP chat etc..) are just DETAILS, and should be PLUGIN at the end of development.

It sounds like being the opposite way of thinking of GOOS.  

Your idea is:  Make a walking skeleton at the very beginning to be sure of our components integration (web server, database, build script etc..).

                    Then, each acceptance test should be wrote in an end-to-end way also. 

His:  Forget about boundaries, just deals with in-memory java objects. "You need HTML page?  simulate one in-memory !"  "All decisions about technical components should be defer !". No Selenium, no real UI, nor real database etc...

How to deal with this "contradiction" ? 

[Nat Pryce]

At the start of a project, my acceptance tests usually run end-to-end, because when a system is small there is no need to separate it into modules and I am not sure what the appropriate separation should be yet. As the design emerges through, a clean separation between domain logic & technical infrastructure will appear. Often a ports-and-adaptors architecture, as we describe in GOOS. My tests around the adaptors give me confidence that the domain model integrates with the technical infrastructure predictably. Then I can run acceptance tests directly against the domain model.

However, there are risks running acceptance tests directly against the domain model. 

Writing new features by starting with the domain model and later trying to integrate with technical infrastructure risks the domain model ignoring realities of the technical infrastructure, and therefore the adaptor layers being much more complicated and less efficient than they should be. That's why we recommend working end-to-end, adding thin slices to the entire application. It may be that a new feature doesn't require any changes to technical and adaptor parts -- they would be good candidates for writing acceptance tests directly against the domain model.

Running acceptance tests only against the domain model risks coupling the acceptance tests to the domain model.  The only option, then, for making them pass is to write more domain model, rather than making systemic changes that achieve the same effect. For example, on one project we replaced tens of thousands of lines of domain model code with a dozen lines of code that leveraged the capabilities of the message broker we were using, without affecting our system's functionality & greatly improving its performance. 

Some testing frameworks (cucumber or FIT, for example) make it easy to keep technical decisions out of the tests so you can target tests at different levels of the system without changing them. Others (JUnit, for example) make it harder to do so or at least require forethought & discipline to use them that way. But document-driven spec-by-example tools come with their own benefits & drawbacks, so yet more trade-offs...

--Nat

www.natpryce.com

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

[Michael Azerhad]

What a nice answer :)  

I adhere to your way of thinking => preferring to test with an end-to-end vision while it is possible.

I really would like to apply a good practice in my personal project (large project), a social network.

Can you give me some brief guidance/advises?

As the project just kicks off, client comes and presents its expected first feature (it's an example):  List on the page the most active 5 users of my website.

By practicing BDD, he sends me: 

Given I am on the home page

When I click on "top 5 users" button

Then corresponding users are displayed as a list

I don't work with Cucumber, neither Fit, but with Specs2 (since I use Scala) which allows a BDD practice too.

Thus, I translate this "spec" into some Specs2 specification that I'd call:  HomePageSpec

So, within it, my acceptance test would be:   clickOnTop5MostActiveUsersButtonShouldDisplayTheCorresponding5UsersAsAList()

Then, I create some dedicated page object (HomePage), since I expect my test to focus on "what" rather than "how" and write Selenium codes, following the "programming by wishful thinking".

I run it and logically, it fails :)

Therefore, I decide to start with TDD workflow by initialize a use-case test class corresponding to this feature: UserServicesTest. Logically, this class belongs to the application service layer (since I follow DDD and port-and-adapters architecture). In it, a test method would be so: retrieve5MostActiveUsersShouldReturn5MostActiveUsers().

With the same guidance (programming by wishful thinking), I write my test and I create some "minimal" implementation, in order to make the test pass.

It would certainly allow me to define some others class (entities, potential domain service, repository etc...).

If passed, I refactor (if needed) and I run my acceptance test: HomePageSpec and check for its success.

If succeeded, I can confirm that my first feature is done.

Am I on a right way?

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

[Steve Freeman]

Top 5 sounds like quite a big first chunk. It implies users and activity. Is there something smaller?

S. 

Steve Freeman

http://www.higherorderlogic.com

Written on a phone, so please allow for typos and short content.  

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

[Michael Azerhad]

Yes, you're right, let's say a simpler feature:  displayAllUsersNameOnScreen()

I wonder whether this style of procedure (Selenium then Unit Tests (using mocks for collaborators, since I'm a mockist) is good way of doing.

[Steve Freeman]

what is the most important thing about your system? Probably not that it's got users. You can start with a feature that assumes a single user, if that's what counts.

S

[Michael Azerhad]

A main feature is to display some users having some criterias corresponding to other users.

Thus, a main display on the home page would be a list of users.

[Nat Pryce]

On Sunday, 16 June 2013 13:50:03 UTC+1, Michael Azerhad wrote:

I adhere to your way of thinking => preferring to test with an end-to-end vision while it is possible.

I don't always prefer to test end-to-end.  It's a trade-off -- an engineering judgement. Usually testing against the domain model is fastest and most reliable.  But sometimes (e.g. early in the project) the cost of modularisation isn't worth it and I like to address integration risks as early as possible. And sometimes (e.g. in projects with a large integration aspect) the domain model doesn't always cover enough of the complexity for acceptance tests against the domain model to be very meaningful.

 

As the project just kicks off, client comes and presents its expected first feature (it's an example):  List on the page the most active 5 users of my website.

By practicing BDD, he sends me: 

Given I am on the home page

When I click on "top 5 users" button

Then corresponding users are displayed as a list

As Steve has said, it's not a great first feature. Would anybody visit a site if the only thing it does is show who's visited the site? :-)  

Apart from that, this test contains a lot of technical details. I'd consider clicking on a button, and displaying a list, and maybe even "home page" technical details. If I remove those, I have to write about what it means for a user to be "active", which surfaces the domain logic the system has to implement.  This might produce a test like:

Given the users

| User Name | Visits in the last Month |
+-----------+--------------------------+
| Alice     | 10                       |

| Bob       |  5                       |

| Carol     | 12                       |

| David     | 40                       |

| Eve       | 23                       |

| Frank     |  0                       |

| Grace     | 12                       |

| Harry     |  4                       |

| Ivy       |  7                       |

| Joe       | 18                       |

The most active users are shown to be:

| User Name |

+-----------+

| David     |

| Eve       |

| Joe       |

| Carol     |

| Grace     |

Then I could target the test at either an end-to-end test through the web UI with WebDriver or somesuch, or at the logic behind the front-end.

--Nat

[Michael Azerhad]

Thanks a lot Nat, I understand :)

Just one more question, is it worth to create an integration test for page objects? (page object pattern with Selenium). Exemple:  HomePageObject => HomePageObjectTest

Or I can count on it without needing its test, since if he were corrupted, errors would be easy to recover since the whole test would certainly fail. (not finding expected HTML components for instance) 

(Sorry if you received two mails, for messages I've just deleted :), they were not revealing my exact thought )

Michael

[Matteo Vaccari]

On Mon, Jun 17, 2013 at 1:34 AM, Nat Pryce <nat....@gmail.com> wrote:

On Sunday, 16 June 2013 13:50:03 UTC+1, Michael Azerhad wrote:

I adhere to your way of thinking => preferring to test with an end-to-end vision while it is possible.

I don't always prefer to test end-to-end.  It's a trade-off -- an engineering judgement. Usually testing against the domain model is fastest and most reliable.  But sometimes (e.g. early in the project) the cost of modularisation isn't worth it and I like to address integration risks as early as possible. And sometimes (e.g. in projects with a large integration aspect) the domain model doesn't always cover enough of the complexity for acceptance tests against the domain model to be very meaningful.

Thanks Nat and Steve and Michael,

this thread is very useful.

My 2 cents of experience in helping people that are new to testing at all is that they will sometimes spend hours wondering how to test some piece of technical infrastructure like e.g., JSF beans or Spring-injected databases.  I then suggest to apply some variation of Humble Dialog/Humble Object to get the most interesting bit of the code under test with a very easy-to-write and quick-to-execute unit test.  I explain that at this stage, writing a true end-to-end test is not as important as being able to comfortably test the interesting bits.  I also stress that when something is hard to test, it's better to decouple the production code than to learn more fancy concrete-class-mocking techniques.

(This is similar to what Arlo Belshee suggests [0] "I split the interesting part from the hard-to-test part. Then I test the interesting part. There is no need (or value) to testing the hard part if I've already tested all the business value")

So this is another variable in the engineering trade-off: how much testing experience the team has.

Matteo

[0] http://arlobelshee.com/post/easily-eliminate-most-mocks

[Björn Rasmusson]

Matteo Vaccari wrote:

On Mon, Jun 17, 2013 at 1:34 AM, Nat Pryce <nat....@gmail.com> wrote:

On Sunday, 16 June 2013 13:50:03 UTC+1, Michael Azerhad wrote:

I adhere to your way of thinking => preferring to test with an end-to-end vision while it is possible.

I don't always prefer to test end-to-end.  It's a trade-off -- an engineering judgement. Usually testing against the domain model is fastest and most reliable.  But sometimes (e.g. early in the project) the cost of modularisation isn't worth it and I like to address integration risks as early as possible. And sometimes (e.g. in projects with a large integration aspect) the domain model doesn't always cover enough of the complexity for acceptance tests against the domain model to be very meaningful.

Thanks Nat and Steve and Michael,

this thread is very useful.

My 2 cents of experience in helping people that are new to testing at all is that they will sometimes spend hours wondering how to test some piece of technical infrastructure like e.g., JSF beans or Spring-injected databases.  I then suggest to apply some variation of Humble Dialog/Humble Object to get the most interesting bit of the code under test with a very easy-to-write and quick-to-execute unit test.  I explain that at this stage, writing a true end-to-end test is not as important as being able to comfortably test the interesting bits.  I also stress that when something is hard to test, it's better to decouple the production code than to learn more fancy concrete-class-mocking techniques.

My 2 cents on this topic is:
- We want acceptance tests, to agree on the spec for a feature and to verify that the feature works as intended
- We want end-to-end tests, to make sure that all parts of the system works together as a whole

Automating every acceptance test as an end-to-end test is not always the best option. It could be because the tests will be to slow, or because it is hard to test through the UI etc. When (all) acceptance tests are not automated as end-to-end tests, for instance they are automated against the domain model, we still need to make sure we have enough end-to-end tests to be confident that the system works as a whole. One option can be that a well chosen subset of the acceptance test are (also) executed end-to-end, or maybe the acceptance test suite is complemented with other end-to-end tests.

The rule "Every acceptance test should be an end-to-end test" is simple, unfortunately it is to simple, as Nat say it is an engineering judgement.
 
Regards
Björn

[Matteo Vaccari]

On Mon, Jun 17, 2013 at 10:32 AM, Björn Rasmusson <bj.ras...@gmail.com> wrote:

...

Automating every acceptance test as an end-to-end test is not always the best option. It could be because the tests will be to slow, or because it is hard to test through the UI etc. When (all) acceptance tests are not automated as end-to-end tests, for instance they are automated against the domain model,

Between testing-through-the-ui and testing against the domain model there is a middle ground, that is testing through application services (what Uncle Bob calls "interactors") 

Matteo

[Nat Pryce]

On 17 June 2013 09:32, Björn Rasmusson <bj.ras...@gmail.com> wrote:

- We want acceptance tests, to agree on the spec for a feature and to verify that the feature works as intended
- We want end-to-end tests, to make sure that all parts of the system works together as a whole

And, if doing TDD:

- We want tests to give us feedback on the quality of our *design* as well as implementation.

Objections about end-to-end tests and testing through the GUI, even from TDD advocates, seem to be about post-hoc testing, in which the system is a fixed thing and tests exist only to check it.  But I find that if you use system tests to drive the design of the system you get useful design improvements that simplify interfaces (even UI) and drive the design of monitoring and management interfaces that help support the system when deployed.

--Nat

--
http://www.natpryce.com

[Steve Freeman]

+a lot

On 17 Jun 2013, at 13:36, Nat Pryce wrote:
> And, if doing TDD:
>
> - We want tests to give us feedback on the quality of our *design* as well
> as implementation.
>
> Objections about end-to-end tests and testing through the GUI, even from
> TDD advocates, seem to be about post-hoc testing, in which the system is a
> fixed thing and tests exist only to check it. But I find that if you use
> system tests to drive the design of the system you get useful design
> improvements that simplify interfaces (even UI) and drive the design of
> monitoring and management interfaces that help support the system when
> deployed.

Steve Freeman

Winner of the Agile Alliance Gordon Pask award 2006
Book: http://www.growing-object-oriented-software.com

+44 797 179 4105
Twitter: @sf105
Higher Order Logic Limited
Registered office. 2 Church Street, Burnham, Bucks, SL1 7HZ.
Company registered in England & Wales. Number 7522677

[Michael Azerhad]

IMHO, testing use-cases directly (without coupling with boundaries like UI or database), as Uncle Bob promotes give the illusion to be more productive.

IMHO, if you are already sure about your technical boundaries, testing end-to-end may be longer to implement and to run, but it compensates the wasted time by manual testing before a delivery (with the stress that comes with it).   "My SQL query crashed !! Why this menu doesn't appear on this page ?! "   etc..   Many things that could be catch earlier by taking in account UI and Database in your acceptance test.

I imagine also a company which knows a huge turnover.. what will be the reaction of new developers:  "huh.....what does this screen is about to do?, I want to change the way of listing elements, it's ugly .. "  " Nooooo, don't touch, we haven't test to ensure the modification".

According to me, after thinking a lot about it, if you have time, do end-to-end test. Of course, this end-to-end test would not prevent a design with loose coupling between boudaries and use-cases/domain layer.

[Björn Rasmusson]

Michael Azerhad wrote:

IMHO, testing use-cases directly (without coupling with boundaries like UI or database), as Uncle Bob promotes give the illusion to be more productive.

IMHO, if you are already sure about your technical boundaries, testing end-to-end may be longer to implement and to run, but it compensates the wasted time by manual testing before a delivery (with the stress that comes with it).   "My SQL query crashed !! Why this menu doesn't appear on this page ?! "   etc..   Many things that could be catch earlier by taking in account UI and Database in your acceptance test.

I imagine also a company which knows a huge turnover.. what will be the reaction of new developers:  "huh.....what does this screen is about to do?, I want to change the way of listing elements, it's ugly .. "  " Nooooo, don't touch, we haven't test to ensure the modification".

According to me, after thinking a lot about it, if you have time, do end-to-end test. Of course, this end-to-end test would not prevent a design with loose coupling between boudaries and use-cases/domain layer.

I agree completely, acceptance testing end-to-end is the primary option.
And if you for some reason choose to not automate the acceptance tests for some feature end-to-end, you still need to have enough end-to-end testing to allow you to sleep well at night.

Regards
Björn

[Seb Rose]

On 17 June 2013 13:36, Nat Pryce <nat....@gmail.com> wrote:

Objections about end-to-end tests and testing through the GUI, even from TDD advocates, seem to be about post-hoc testing, in which the system is a fixed thing and tests exist only to check it.  But I find that if you use system tests to drive the design of the system you get useful design improvements that simplify interfaces (even UI) and drive the design of monitoring and management interfaces that help support the system when deployed.

I don't have general objections to end-to-end or through-GUI testing - these sorts of system tests are useful to drive out design. The objection is often raised when ALL acceptance tests are built this way. The common objections relate to speed and brittleness.

Speed: end-to-end tests exercise more of the application and, therefore, will take longer to run. This may not be a problem for you (yet), but you can almost always get as much coverage by making most of your acceptance tests exercise interesting application behaviour using less than the whole application stack.

Brittleness: ene-to-end tests use all of the 'moving parts' of your application (including infrastructure). System tests ensure that all these components play together nicely. Acceptance tests demonstrate that specific application functionality has been delivered. Why expose your acceptance tests to the risk of intermittent/transient failures? Or to put the other way - what's the benefit of doing this?

Cheers

Seb

--
ACCU - Professionalism in Programming - http://accu.org

http://www.claysnow.co.uk
http://twitter.com/#!/sebrose
http://uk.linkedin.com/in/sebrose

[Seb Rose]

This is an interesting thread covering a crucial question that crops up all the time.

One approach, that I have blogged about, allows the end-to-end-ness of acceptance tests to be varied using Cucumber tags. This approach is not limited to Cucumber, however.

Blog: http://claysnow.co.uk/?p=175045733

On 17 June 2013 09:32, Björn Rasmusson <bj.ras...@gmail.com> wrote:

--

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

On Monday, 17 June 2013 14:16:58 UTC+1, Seb Rose wrote:

On 17 June 2013 13:36, Nat Pryce <nat....@gmail.com> wrote:

Brittleness: ene-to-end tests use all of the 'moving parts' of your application (including infrastructure). System tests ensure that all these components play together nicely. Acceptance tests demonstrate that specific application functionality has been delivered. Why expose your acceptance tests to the risk of intermittent/transient failures? Or to put the other way - what's the benefit of doing this?

Speed is a concern, I agree.  But brittleness/intermittency is highlighting design issues.

Why is the system brittle? Why does it intermittently fail? Or why do the tests intermittently fail to understand what the system is doing?  Those are issues I'd want to address.  I don't want a system that has intermittently failing behaviour when deployed, or for which management operations intermittently fail.

What's the benefit of doing this?  It gives you more options as to implementation strategy and drives out more extensive robust monitoring and management interfaces.  If acceptance tests only run against the domain model, the only way to add functionality is to add code to the domain model.  Deleting the domain model entirely won't be easy to do, or even envisage.  Is that worth the slowness and brittleness?  It depends on the system.

I too think that the best approach, as you wrote in your other post, is to be able to target tests at different amounts of the system.  But I've always found that difficult: how to stop implicit assumptions about the level at which you're testing make it hard to retarget them at other levels of the system?

--Nat

[Michael Azerhad]

Seb Rose, do you have a brief sample somewhere showing the concept of that cucumber tag interchanging the scope (end-to-end or domain) of the test ? 

How could a scenario implementation oriented UI first, like Selenium be....mocked and tackling domain model (service rather), without altering totally the implementation ?

By the way, nice article on your blog :)

Michael

[Nat Pryce]

On 17 June 2013 01:23, Michael Azerhad <michael...@gmail.com> wrote:

... I chose to start to implement the feature by creating a unit test of my "future" controller (I use Play framework). So, UserControllerTest is firstly created, leading to create a UserServicesImplTest. 

Implementation of the UserServicesImplTest is totally trivial, mocking a UserRepository returning an empty list. Of course, I create also a real UserRepository dealing with a simple NoSQL request to find Users. This latter will be call by the end-to-end acceptance test.

I make UserServiceImplTest passes easily and then UserControllerTest (containing a mocked UserServicesImplTest in order to be truly isolated)

(I agree that a real TDD procedure doesn't know anything about layers at the very beginning... but in order to speed up a little, I allow me just this step jump.)

No! :-)

You're missing the fundamental aspect TDD if you start by thinking up a load of layers and patterns, write tests that assert that code fits that design and then write code to fit into the design that's now concreted in by your tests.

Really try to start with the *smallest* test that you can.  Try to write the *simplest* implementation that makes the test pass.  Let structure emerge by refactoring.  As structure emerges choose meaningful names that expresses how the code relates what the system's users do and how they talk about the work. You may be surprised as to the design that emerges.  E.g. maybe there will be no classes named ThingyImpl, WotsitService or GizmoRepository.

For a start, how do your users or customer(s) refer to users of your system?  As a user base?  A user population?  Cohort? Community?  I bet they don't say "User Repository"!

The point of a walking skeleton is to help you understand the *external* integration points between your system (and team) and the other system's (and teams) you need to integrate with.  That may be third-party services, operations teams, network monitoring infrastructure mandated within the organisation, etc. etc. I would not include a database component that's fully under your control and that you deploy as part of your app in a walking skeleton.  That's just an internal implementation choice that one can very often defer until later.

--Nat

--
http://www.natpryce.com

[Michael Azerhad]

Understood for layers :) I will follow a pure TDD procedure so, letting my code to emerge them, if happens, without anticipating them :)

And I agree, customers may not even know what is a database.. :)

Thus, why do we qualify the walking skeleton to be "end-to-end"? Should I rather deal with in-memory storage (simple POJO for instance) in order to be more flexible to future decision (deferring storage choices) if my TDD makes emerge the need for a storage?

Why the choice of UI implementation, like GOOS presents with a Swing interface, is made at walking skeleton time? Why this choice should not be deferred, like database should?

Can't I say: "Customers may not even know about kind of UI interfaces"?

By "end-to-end" terms, I understand the notion of concrete mechanisms…not really just a simple "understanding" of necessary components… 

I'm a bit confused so :)  

Thanks Nat :)

[Ville Svärd]

Great answer, thanks for that Nat!

--

vs

2013/6/18 Nat Pryce <nat....@gmail.com>

--

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

--
vs.

[Nat Pryce]

On 18 June 2013 14:06, Michael Azerhad <michael...@gmail.com> wrote:

Understood for layers :) I will follow a pure TDD procedure so, letting my code to emerge them, if happens, without anticipating them :)

And I agree, customers may not even know what is a database.. :)

Thus, why do we qualify the walking skeleton to be "end-to-end"?

Because it exercises the system through its "ends" ("edges" might be a better term), and the development/deployment process from the (developers committing a change) to end (system running in a deployment environment).

 

Should I rather deal with in-memory storage (simple POJO for instance) in order to be more flexible to future decision (deferring storage choices) if my TDD makes emerge the need for a storage?

I do that.  Sometimes I've found the system has no need for a database (and we've saved ourselves an expensive Oracle license).

 

Why the choice of UI implementation, like GOOS presents with a Swing interface, is made at walking skeleton time? Why this choice should not be deferred, like database should?

Can't I say: "Customers may not even know about kind of UI interfaces"?

Because the users are outside the system.  The UI is one interface with which your system connects to the wider world.

The database is an internal implementation detail (except when it isn't, for example if you let people use your database as an integration point, in which case you've got much bigger problems to deal with!).

 

By "end-to-end" terms, I understand the notion of concrete mechanisms…not really just a simple "understanding" of necessary components… 

I'm a bit confused so :)  

Thanks Nat :)

On Tuesday, June 18, 2013 2:45:59 PM UTC+2, Nat wrote:

On 17 June 2013 01:23, Michael Azerhad <michael...@gmail.com> wrote:

... I chose to start to implement the feature by creating a unit test of my "future" controller (I use Play framework). So, UserControllerTest is firstly created, leading to create a UserServicesImplTest. 

Implementation of the UserServicesImplTest is totally trivial, mocking a UserRepository returning an empty list. Of course, I create also a real UserRepository dealing with a simple NoSQL request to find Users. This latter will be call by the end-to-end acceptance test.

I make UserServiceImplTest passes easily and then UserControllerTest (containing a mocked UserServicesImplTest in order to be truly isolated)

(I agree that a real TDD procedure doesn't know anything about layers at the very beginning... but in order to speed up a little, I allow me just this step jump.)

No! :-)

You're missing the fundamental aspect TDD if you start by thinking up a load of layers and patterns, write tests that assert that code fits that design and then write code to fit into the design that's now concreted in by your tests.

Really try to start with the *smallest* test that you can.  Try to write the *simplest* implementation that makes the test pass.  Let structure emerge by refactoring.  As structure emerges choose meaningful names that expresses how the code relates what the system's users do and how they talk about the work. You may be surprised as to the design that emerges.  E.g. maybe there will be no classes named ThingyImpl, WotsitService or GizmoRepository.

For a start, how do your users or customer(s) refer to users of your system?  As a user base?  A user population?  Cohort? Community?  I bet they don't say "User Repository"!

The point of a walking skeleton is to help you understand the *external* integration points between your system (and team) and the other system's (and teams) you need to integrate with.  That may be third-party services, operations teams, network monitoring infrastructure mandated within the organisation, etc. etc. I would not include a database component that's fully under your control and that you deploy as part of your app in a walking skeleton.  That's just an internal implementation choice that one can very often defer until later.

--Nat

--
http://www.natpryce.com

--

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

--
http://www.natpryce.com

[Michael Azerhad]

I really appreciate your answer Nat :)

Moreover, despite the early choice of UI (essential for customers feedback as you've just explained), I well imagine that PageObject pattern is there to help to mask the UI implementation and letting the possibility in the future to change this UI implementation, without breaking acceptance tests.

The more I practice TDD (recently), the more I enjoy it :)  However, a lot of huge companies, like investment banking would just say (I lived it):  "Code quickly, dirty and shut up, we have already QA to test" ...  Ietting GOOS practice to only home. Frustrating :)  

Michael 

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.
 
 

--
http://www.natpryce.com

[Lance Walton]

On 18 Jun 2013, at 16:03, Michael Azerhad <michael...@gmail.com> wrote:

> However, a lot of huge companies, like investment banking would just say (I lived it): "Code quickly, dirty and shut up, we have already QA to test" ... Ietting GOOS practice to only home. Frustrating :)

I've been working with investment banks for the past 14 years. I agree that they often tend to start from the point you describe. The answer is "No". They come around.

[Michael Azerhad]

I've been working for an IB for just 3 years. My answer was "No" :)  They retort: "Either you adopt our "programming rules" (more than bad, really, no OO, only procedural with Java, no unit tests at all etc...), or just leave the place Michael"  => I left and I don't regret it at all.    They don't come around in my case.

Michael

[Lance Walton]

Yes. There are some that are unbelievably broken. I've been involved in turning a couple of those around (hard work), and I've also done my share of leaving when it's obviously broken beyond repair...

[Michael Azerhad]

Hope that mentalities will change in some years ;)  The lack of senior programmers and agile experts in environment like bank is also incredible (from what I noticed). There are very few people to convey some good guidances in there. Maybe that's the case just in France..(I live in France) where it's always known that people rarely want to change deeply their habits :)