Simulate complete form submit in unit tests

dkorpar
Member | 136
+
0
-

I have tried to set all $_POST fields, call $form->setSubmitedBy but I never really hitted fully working example of form submit, what would be all steps required to get that and to have fully working flow in unit tests?

Petr Parolek
Member | 455
+
+1
-

You can use Mango Tester, see https://github.com/…nterTest.php#…

dkorpar
Member | 136
+
-2
-

@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!

Last edited by dkorpar (2021-03-14 12:23)

dsar
Backer | 53
+
+1
-

Or you may be inspired by here .

They are tested with nette tester but the code is easily adaptable to phpunit

Last edited by dsar (2021-03-14 12:38)

Marek Bartoš
Nette Blogger | 1273
+
0
-

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
+
0
-

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
+
0
-

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
+
0
-

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
+
+3
-

nette/tester has few huge flaws for me and because of that I'm using allways exclusively phpunit

  1. nette/tester plugin for phpstorm was never really on level of phpunit plugin and plus it were brooken few times already for long time
  2. reading coverage in html instead of directly in IDE in 2021 is unnaceptable for me
  3. wierd behaviour when not providing -C flag and then running completelly without any php.ini and you're then missing all extensions
  4. 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
+
0
-

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
+
0
-

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
+
+1
-

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?

dkorpar
Member | 136
+
0
-

@dakur exactly.

dakur
Member | 493
+
0
-

@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)

dsar
Backer | 53
+
0
-

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

dkorpar
Member | 136
+
0
-

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
+
0
-

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)

dkorpar
Member | 136
+
0
-

yup, that's what I'm doing, pretty much same as one example I posted here…
Assert that validation error is properly displayed after form submit.

dakur
Member | 493
+
0
-

@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
+
+1
-

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.