1

The Symfony testing documentation doesn't really mention a distinction between functional tests and integration tests, but my understanding is that they are different.

The Symfony docs describe functional testing like this:

  1. Make a request;
  2. Test the response;
  3. Click on a link or submit a form;
  4. Test the response;
  5. Rinse and repeat.

While the Ruby on Rails docs describe it like this:

  1. was the web request successful?
  2. was the user redirected to the right page?
  3. was the user successfully authenticated?
  4. was the correct object stored in the response template?
  5. was the appropriate message displayed to the user in the view?

The Symfony docs seem to be describing something more akin to integration testing. Clicking links, filling out forms, submitting them, etc. You're testing that all these different components are interacting properly. In their example test case, they basically test all actions of a controller by traversing the web pages.

I am confused why Symfony does not make a distinction between functional and integration testing. Does anyone in the Symfony community isolate tests to specific controller actions? Am I overthinking things?

Community
  • 1
  • 1
Brian
  • 6,656
  • 11
  • 41
  • 75
  • I would abstract all this in BDD.... and you're comparing a generic symfony example with a ROR example containing even data persisting and user authentication... – Guilherme Viebig Feb 23 '15 at 21:36
  • My point with the comparisons is that Symfony suggests writing functional tests that are doing more than just making a request and testing the response. They are suggesting that you then "click" and "browse" the result to test other components. The Rails docs don't suggest this, since they talk about that in the integration tests docs – Brian Feb 25 '15 at 14:21
  • Rails don't have a final approach on testing. Thats just one way of doing it. – Guilherme Viebig Feb 26 '15 at 14:42

4 Answers4

4

  • Unit testing refers to test methods of a class, one by one, and check that they make the right calls in the right context. If those methods use dependencies (injected services or even other methods of that class), we're mocking them to isolate the test to the current method only.

  • Integration testing refers to automatically test a feature of your application. This is checking that all possible usage scenarios for the given feature work as expected. To do such tests, you're basically using the crawler, and simulate a website user to work through the feature, and check the resulting page or even resulting database data are consistent.

  • Functional testing refers to manually challenge the application usability, in a preproduction environment. You have a Quality Assurance team that will roll out some scenarios to check if your website works as expected. Manual testing will give you feedbacks you can't have automatically, such as "this button is ugly", "this feature is too complex to use", or whatever other subjective feedback a human (that will generally think like a customer) can give.

Alain Tiemblo
  • 32,952
  • 14
  • 114
  • 147
1

The way I see it the 2 lists don't contradict eachother. The first list (Symfony) can be seen as a method to provide answers for the second list (Rails).

Both lists sound like functional testing to me. They use the application as a whole to determine if the application satisfies the requirements. The second list (Rails) describes typical questions to determine if requirements are met, the first list (Symfony) offers a method on how to answer those questions.

Integration tests are more focused on how units work together. Say you have a repository unit that depends on a database abstraction layer. A unit test can make sure the repository itself functions correctly by stubbing/mocking out the database abstraction layer. An integration test will use both units to see if they actually work together as they should.

Another example of integration testing is to use real database to check if the correct tables/columns exist, and if queries deliver the results you expect. But also that when a logger is called to store a message, that message really ends up in a file.

PS: Functional testing that actually uses a (headless) browser is often called acceptance testing.

Jasper N. Brouwer
  • 20,417
  • 4
  • 49
  • 76
1

Both referenced docs describes functional tests. Functional tests are performed from user perspective (typically on GUI layer). It tests what user will see, what will happen if user submit form or will click on some button. Does not matter if it is automatic or manual process.

Then there are integration and unit tests. These test are on lower level. Basic prediction for unit tests is that they are isolated. You can test particular object and its methods but without external or real dependecies. This is what are mocks for (basically mock simulates real object according to unit test needs). Without understanding of IOC is really hard write isolated tests.

If you are writing tests using real/external dependencies (no mocks), you write integration tests. Integration tests can test cooperation of two objects or whole package/module including querying database, sending mails etc.

kba
  • 3,880
  • 2
  • 13
  • 24
1

Yes, you are overthinking things ;)

I don't know why Symfony or Ruby on Rails states things like that. There is a time where testing depends on the eye it's looking at it. Bottom line: it doesn't matter the name. The only important thing is the confidence that the test gives to you on what you are doing.

Apart from that, the tests are alive and should evolve with your code. I sometimes test only for a specific HTTP status code, other times I isolate a module and unit test it... depends on the time I have to spend, the benefits, etc.

If I have a piece of code that only is used in a controller, I usually go for a functional test. If I'm making an utility I usually go for unit testing.

javierfdezg
  • 1,969
  • 1
  • 19
  • 31