Simulate complete form submit in unit tests
- Marek Bartoš
- Nette Blogger | 1273
It's better to test presenter and components completely, same way as user would use them, instead of manually creating request. I would recommend Cypress, but many alternatives are available too – like Selenium, Behat or Symfony Panther
Last edited by Mabar (2021-03-14 12:46)
- Marek Bartoš
- Nette Blogger | 1273
dsar wrote:
Or you may be inspired by here .
They are tested with nette tester but the code is easily adaptable to phpunit
It's useful for testing custom inputs, but not really for real world scenarios.
- dsar
- Backer | 53
Considering how javascript is abused today with forms, you are generally right and a headless browser solution is needed.
But in my opinion a form should work also with javascript disabled (with
multiple submits to update the form state).
One of the big advantages is that dynamic forms are testable without a headless
browser
Last edited by dsar (2021-03-14 13:21)
- Petr Parolek
- Member | 455
dkorpar wrote:
@PetrParolek that's for nette tester which is not an option for me…
But probably I can take out code which I need in order to make this work with phpunit, although it won't be easy…
thanks anyway!
What do you have against Nette Tester? Why do you use PHPUnit only?
- dkorpar
- Member | 136
nette/tester has few huge flaws for me and because of that I'm using allways exclusively phpunit
- nette/tester plugin for phpstorm was never really on level of phpunit plugin and plus it were brooken few times already for long time
- reading coverage in html instead of directly in IDE in 2021 is unnaceptable for me
- wierd behaviour when not providing -C flag and then running completelly without any php.ini and you're then missing all extensions
- Not being able to just right click on method name anywhere in phpstorm and just start debugging
All in all works fine and biggest issue is not good enough phpstorm plugin a
nd really don't understand why -C is needed for default behaviour of all other
commands. Basically I don't see any reason why I would choose nette/tester
over phpunit, there's nothing really there that I would benefit from.
Not to mention that whenever U're stuck in nette/tester you're on your own and
hard to get out, while on phpunit first stack overflow result solves
anything…
My apologiez for speaking against package that is part of this awesome package, it's just how I see things.
Last edited by dkorpar (2021-03-15 13:35)
- dsar
- Backer | 53
Well, phpunit is a huge beast compared to nette tester (phpunit is bigger than the whole nette framework and it's increasing its size as version grows up) and of course it's targetting more compelling features.
Generating code coverage in HTML is pretty universal and independent by any IDE or platform. It's the right choice if you are targetting simplicity and economy (and people choose nette for these two reasons, at least me)
- dkorpar
- Member | 136
Mabar wrote:
It's better to test presenter and components completely, same way as user would use them, instead of manually creating request. I would recommend Cypress, but many alternatives are available too – like Selenium, Behat or Symfony Panther
thanks, but I'm not interested here in end to end tests, I'm mostly thinking
on unit tests on contributte/forms-bootstrap where I would match complete
output with expected output based on different validation options/settings
provided after submit…
something simple as:
public function testDefaultButton(): void
{
$form = new BootstrapForm();
$btn = $form->addButton('btn', 'caption');
$this->assertEquals('<button type="button" name="btn" class="btn btn-secondary">caption</button>', $btn->getControl()->render());
}
but thanks for effort, definitively makes sense in other cases
Last edited by dkorpar (2021-03-16 09:09)
- dakur
- Member | 493
thanks, but I'm not interested here in end to end tests, I'm mostly thinking on unit tests on contributte/forms-bootstrap where I would match complete output with expected output based on different validation options/settings provided after submit…
@dkorpar In other words, you want to test that for various input it renders correct UI state – correct error message?
- dakur
- Member | 493
@dkorpar Ok. I know that the question was how not if but still I think it's not a good idea (if the reason is not budget of course 🙂). You should either test data structures for testing logic, or user-scenario with appropriate testing tool (e.g. mentioned above cypress) which target on what you see, not what there is technically. Testing rendered stuff is highly risky as rendered output is likely to change.
Last edited by dakur (2021-03-16 11:27)
- dkorpar
- Member | 136
dsar wrote:
If contributte/forms-bootstrap is already a tested library there is no reason to re-test it in your project.
You should test your form processing logic as dakur said
I'm maintainer of contributte/forms-bootstrap.
I'm thinking of adding more tests there and those after submit are missing.
testing rendered outputs in those cases are pretty fine IMHO.
Ofcours that this sounds wrong if we're talking about project which is using it
but that's not a case here.
Last edited by dkorpar (2021-03-16 12:39)
- dakur
- Member | 493
I'm maintainer of contributte/forms-bootstrap.
Good to know… 😄 So you want to test that
BootstrapRenderer::render()
does its job well = produces expected
HTML? Or can you be specific on one single example of what are you trying to
achieve?
Last edited by dakur (2021-03-16 13:11)
- dakur
- Member | 493
@dkorpar I don't know, how exactly you work with
nette/forms
or nette/application
's Form, but setting
custom Nette\Http\Request
with mocked values would not help?
Nette\Forms\FormFactory
does it for example, or there is internal
Nette\Forms\Form#setHttpRequest()
method.
Also note that there must be that _do
hidden input field present
so that Nette knows that the form has been submitted.
Last edited by dakur (2021-03-16 14:52)
- dkorpar
- Member | 136
In case someone else bumps here, solution for me is: https://github.com/…/nette-tests
It's for phpunit, solves presenter/form submit and DI container.