Rewriting Behat tests about knpradbundle HOT 16 CLOSED

I'm not sure what you mean with "behat is writing code, testing code is the phpspec role".

With behat, we're not testing code units here, but the behavior of the knprad bundle in a "realisitc" environment.

Actually, it's more functional/system tests, and it could be written with tools like phpunit-selenium (mmh), or funk-spec (mmh too, not so stable).

from knpradbundle.

And the "realisitc" life of knp rad is all about classes, yaml files and templates, so if you wanna test its behavior with all those, you'll have to write some.

from knpradbundle.

Other than that, I have nothing against a replacement that could help us testing knprad as a black box.
Feel free to PR a replacement, or refactor the existing features and context if you will.

Instead of writing the php, yml, and twig inline (in the feature files), we could put them as static fixtures in a separate folder.
But we have to think them correctly.

from knpradbundle.

take a look at other examples: https://github.com/phpspec/phpspec/blob/develop/features/code_generation/developer_generates_class.feature

from knpradbundle.

https://github.com/Behat/Behat/blob/master/features/context.feature

from knpradbundle.

I understand the idea of testing that it works by making an application using features of the rad bundle. More than that having a fully working test application proves that every features are working pretty well together.

In the other hand I don't understand why the test code is writed by behat instead of simply being in the app test folder.

What do you think about simply write a little test application using radbundle and testing it with behat ?

from knpradbundle.

that's what I meant by saying:

"Instead of writing the php, yml, and twig inline (in the feature files), we could put them as static fixtures in a separate folder."

from knpradbundle.

My bad I miss the most important part :) .

I modified the title of the issue.

from knpradbundle.

did you forget the other important part, which is that it's kind of a used practice to put code in the feature files?

from knpradbundle.

This is why behat feature files works great as documention. All you need to know to use project are in features files.

from knpradbundle.

Ping @Djeg before I start working on it.

from knpradbundle.

@Nek- not sure if you got the point of

it's kind of a used practice to put code in the feature files

Most of the tools that uses behat to test itself write php, yaml, .. code inside the feature itself. Why do differently ?

from knpradbundle.

Well, question is do we really need functional testing ?

If yes then fixtures code files it's an idea, like code inside features. For my part i prefer code inside features, not so many files to maintain.

But my heart goes to the simplest (but no functionaly tested) way :). Remove functional test. I agree with the fact that spec can not cover the macros behavior of a bundle. But if code is well decoupled and speced then i think behat features is overkill 'cause if someone has some functional troubles, it open an issue and we work on it ;).

from knpradbundle.

we've already tagged some very well unit-tested code and it wasn't properly integrated, which resulted in simply fatal errors once used as a registered bundle.

Some code can be the best unit-tested code on earth, and independantly badly integrated.

Starting from this point, I understood we need integration/functional tests for rad-bundle.

from knpradbundle.

well, you're right.

Devil in me, but i'm stiil thinking. I understand the point of integration/functional testing. My argument is just why not maintain functional/integration by just trust the developer code and of course the reviewer ? Mistakes are human, but we have issues ? And i have no time to repair all the behat :(.

BTW : Any commits on #170 is welcome ! If we have to keep behat, then we have to repair it.

from knpradbundle.

done.

from knpradbundle.