Integration Tests

[d.ca...@gmail.com]

Hi people,

Well, acording to (B)TDD theory, we should only code a feature if we wrote an integration test that covers it and it's failing. The big deal is that we've coded restuflie-py with only one big integration test. Its intention is to cover hypermedia, but it does cover others features too. The point is that we MUST have integration tests for basic functionalities too, like a simple POST, GET, etc. 

Imagine this situation:  a friend told you to use restfulie in your project to easilly interact with REST resources. Then you go to the project's github and look the specs, and what you find? A spec, using hypermedia, opensearch, and other "complex" things. The new user will surelly be confused, he just wants to know how to do a simple HTTP action.

I can code the basics test with a fake web server using Flask, a micro-webframework (it depends only of werkzeug and jinja2). It wouldn't take so much time and we'll have a nice tests coverage that can be usefull as a documentation for our users too.

We must do a test specially for opensearch itself. The idea is to show to who're reading how to use it.

What do you think about it?

--
Douglas Camata
Graduando em Ciência da Computação (UENF)

Blog: http://blog.douglascamata.net

Github: http://github.com/douglasamata

Twitter: @douglascamata

Skype: douglas_camata

-----------------------------------
Linux User #509211

[Guilherme Silveira]

Hi Douglas,

Summing up: Great idea, go for it!

The big + on using the acceptance test is that it is code, so you can
run it against every release, so feel free to go for it and implement
the structure and first tests, it will be great.

There is no need test every single possibility in a separate
acceptance test case. You can add combinations that make sense and
guarantee typical usage patterns, such as the ones you want to
describe.

For example an acceptance test case that shows how to get and then
follow a link with another get and then with another post. There is no
rule to break those into two tests or stick them into just one, pick
the one that makes sense. The opensearch example is an acceptance test
that guarantees compatibility and also works as an acceptance test
case for basic opensearch usage + get + post + following links.

The only thing we should not forget is to still implement unit
tests... they are more valuable to our design goals than anything
else... doing both acceptance + unit tests is even better

regards

Guilherme Silveira
Caelum | Ensino e Inovação
http://www.caelum.com.br/

[Alexandre Atoji]

If we write more tests using the restbuy? It can helps restfulies from other languages. Because adding one more server + libs to our test suite, I think can make it more complex to run.

Imagine this situation:  a friend told you to use restfulie in your project to easilly interact with REST resources. Then you go to the project's github and look the specs, and what you find? A spec, using hypermedia, opensearch, and other "complex" things. The new user will surelly be confused, he just wants to know how to do a simple HTTP action.

On documentation wiki there are simple examples. I think it's better to read the documentation to use a library than open the source code. ;)

--
Alexandre Atoji

[Guilherme Silveira]

Hi Douglas, Atoji,

The problem with one acceptance test per use case is that end-to-end
tests involving network IO (even if local) are slow and grow really
fast in quantity, bloating the build time really fast :(. Until the
problem is not there (slow build time), no problems... when it
arrives, just group single use cases into functionality tests.

Atoji, yep, if its possible add it to the Restbuy app, so other
languages can write the same acceptance tests.

Regards

Guilherme Silveira
Caelum | Ensino e Inovação
http://www.caelum.com.br/

On Fri, Feb 18, 2011 at 1:08 AM, d.ca...@gmail.com <d.ca...@gmail.com> wrote:
> I've learned this way: write an acceptance test (you can call it an use
> case) to begin the coding. And then write unit tests as I code.
> Thanks Guilherme, I'll do it the better I can.
> Regards,
>
> 2011/2/18 Guilherme Silveira <guilherme...@caelum.com.br>