Acceptance Tests

[Arthur Cláudio Almeida Pereira]

Hi everybody!

  In the web application enviroment, the acceptance tests should be "gui" tests or functional tests?

  When I wrote my first acceptance test should I wrote a test with tools like Selenium or I can test direct from "controller" class? Is it valid?!

  This controller tests shouldn't mock anything, right?

  Sorry about my english

cheers, 

[Raoul Duke]

> In the web application enviroment, the acceptance tests should be "gui"
> tests or functional tests?

why would the testing of it be super different than anything else with
a gui + code behind the gui?

[Stefano Zanella]

Exactly. You should try to think in terms of external interfaces rather than specific components. So in your case, the question is: what will be for the users the interface to your application? In a command line application, it would probably be a command for the input and the stdout for the output. For a webapp it would probably (but not necessarily) be an HTML interface for both the input and the output.

So, to give a more direct answer to your question, yes, I would probably write a test that uses Selenium to drive a web page and stresses a single end to end feature (as GOOS suggests).

Regards,

    Stefano Zanella

--

---

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.

[Arthur Cláudio Almeida Pereira]

Hi! 

  Thanks for the replies.

  @Raoul the difference is the tool used. Like the Stefano said to test my HTML interface i will use Selenium and to test my "controller" I can use an xUnit tool and that's is more easier and faster to create the tests.

2013/4/19 Stefano Zanella <zanella...@gmail.com>

[Leon Hewitt]

There's a discussion I've been having recently that is kind of related to this. 

Lets say we're a few features into the project and we're growing our system with some good separation and a nice hexagonal/ports and adapters architecture.

Then we hit the next feature, which is describing input validation - and there's a ton of these. Do we want to drive each validation through a failing end to end test (and suffer the consequence of a slow test suite)? Or should we drop down a level and drive it through acceptance tests around the domain objects? Maybe a combination of the two - a failing end to end that is quite abstract "should display error when input is invalid" and lower level acceptance tests to cover the detail?

[Steve Freeman]

IANAL, but as you suggest I'd probably extract the validation into something smaller and test that, and have a top level test to show how the system treats an example of validation.

[Luca Minudel]

> Do we want to drive each validation through a failing end to end test (and suffer the consequence of a slow test suite)?

While in unit testing each different behavior of the class is tested in a different test, in acceptance testing is more common to do scenario based testing. This means that all the validations of a features get tested during the same end-to-end acceptance test.

> Or should we drop down a level and drive it through acceptance tests around the domain objects?

The approach described by the test pyramid suggest that when you can effectively test one thing with a unit test you should prefer the unit test over an integration (service in the following picture) or acceptance test (UI in the following picture): http://martinfowler.com/bliki/TestPyramid.html

HTH, Luca

Il giorno mercoledì 24 aprile 2013 08:36:19 UTC+1, docLeon ha scritto:

There's a discussion I've been having recently that is kind of related to this. 

Lets say we're a few features into the project and we're growing our system with some good separation and a nice hexagonal/ports and adapters architecture.

Then we hit the next feature, which is describing input validation - and there's a ton of these. Do we want to drive each validation through a failing end to end test (and suffer the consequence of a slow test suite)? Or should we drop down a level and drive it through acceptance tests around the domain objects? Maybe a combination of the two - a failing end to end that is quite abstract "should display error when input is invalid" and lower level acceptance tests to cover the detail?

On Sat, Apr 20, 2013 at 5:01 PM, Arthur Cláudio Almeida Pereira <arthur.alm...@gmail.com> wrote:

Hi! 

  Thanks for the replies.

  @Raoul the difference is the tool used. Like the Stefano said to test my HTML interface i will use Selenium and to test my "controller" I can use an xUnit tool and that's is more easier and faster to create the tests.

2013/4/19 Stefano Zanella <zanella...@gmail.com>

On Friday 19 April 2013 at 23:18, Raoul Duke wrote:

In the web application enviroment, the acceptance tests should be "gui"

tests or functional tests?

why would the testing of it be super different than anything else with

a gui + code behind the gui?

Exactly. You should try to think in terms of external interfaces rather than specific components. So in your case, the question is: what will be for the users the interface to your application? In a command line application, it would probably be a command for the input and the stdout for the output. For a webapp it would probably (but not necessarily) be an HTML interface for both the input and the output.

So, to give a more direct answer to your question, yes, I would probably write a test that uses Selenium to drive a web page and stresses a single end to end feature (as GOOS suggests).

Regards,

    Stefano Zanella

--

---

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

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

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

[Steve Freeman]

I think the real issue is who the audience is. Outward facing tests might exercise code or a system, it depends on whose interested in understanding the result.

S

[George Dinwiddie]

Arthur,

On 4/19/13 5:10 PM, Arthur Cláudio Almeida Pereira wrote:
> Hi everybody!
>
> In the web application enviroment, the acceptance tests should be
> "gui" tests or functional tests?
> When I wrote my first acceptance test should I wrote a test with
> tools like Selenium or I can test direct from "controller" class? Is it
> valid?!

I advise using multiple levels of testing. (See
http://blog.gdinwiddie.com/2010/03/05/testing-in-depth/) I generally
have business rule tests connect to the system at the lowest level
possible to test the rule. I test user workflow either through the GUI
or just under it (your controller class, I'd guess), depending on the
situation.

- George

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

[Seb Rose]

"...it depends on <pedantry> who's </pedantry> interested ..."

--

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

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

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

[Steve Freeman]

damn.

I'm not pedantic, I just like to get things right...

S

[Ben Biddington]

+1 for not blaming autocomplete...

[Arthur Cláudio Almeida Pereira]

Hi, 

@George wich situation do you prefer to test the UI and wich situation do you prefer to the from the 'controller' ? 

  Your post was very enlightening. I think in the same way. 

@Steve, Well, the target audience is me. I want to develop using the 2 cycles described in GOOS. 

 Initially those tests don't will be seen by the users, just for developers. 

 To me and to the team, is very expensive, to create the Selenium Tests. We prefer create functional tests.

 With this approach we still have a gap in the tests, the UI remains untested and like George said probably will leak some bugs to production.

  We decided to, in a first moment, just create functional tests. This guarantees an end to end test and less bugs in production. This test act like the user and we can see if everything is working.

 

  

2013/4/25 Ben Biddington <ben.bid...@gmail.com>

[George Dinwiddie]

Arthur,

On 4/29/13 4:19 PM, Arthur Cláudio Almeida Pereira wrote:
> Hi,
>
> @George wich situation do you prefer to test the UI and wich situation
> do you prefer to the from the 'controller' ?
> Your post was very enlightening. I think in the same way.

If part of the functionality I'm testing is in the GUI (such as
javascript), I'm likely to test through the GUI.

If the functionality I'm testing is entirely in the back-end, I'll test
under the GUI, backed with a few tests to make sure the GUI is hooked up
correctly.

If the functionality I'm testing is fairly localized, I'll test that
code with acceptance tests in isolation, not deployed to a server.
Likewise if I need to mock some external dependencies to check
conditions I can't otherwise create.

- George

> @*Steve*, Well, the target audience is me. I want to develop using the 2

> cycles described in GOOS.
>
> Initially those tests don't will be seen by the users, just for
> developers.
> To me and to the team, is very expensive, to create the Selenium
> Tests. We prefer create functional tests.
> With this approach we still have a gap in the tests, the UI remains
> untested and like George said probably will leak some bugs to production.
> We decided to, in a first moment, just create functional tests. This
> guarantees an end to end test and less bugs in production. This test act
> like the user and we can see if everything is working.