Simulate complete form submit in unit tests

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

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)

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)

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)

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 exactly.

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.

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