Acceptance tests for large multi-step online form

Question

I have to extend/fix a large online form written by other developer. There is a lot of code, mixing PHP and JS. It's kind of write-only style of coding and I want to redo it completely, but currently I can't.

It works like this:

• It is a wizard-style form with 12 steps - let's call them phases to not confuse with steps of the tests.
• User has to fill at least ~100 fields to finish.
• Some fields are grouped by 3-5. Those groups can be dynamically added and removed with JS.
• Validation is done after submitting each phase. If some errors occured, user is notified immediately and cannot go further until he/she fixes all errors.
• Submitted data is temporarily stored in the session between phases. No permanent storage.
• User cannot skip phases, only sequentially go back and forth to already completed phases.

It is ridiculous to test this thing manually, so I wrote a test using Behat with Mink and Selenium2.

I have only 1 test now, which completes all 12 phases of the form. To go to specific point in the process of filling the form, I created a step definition wich just makes webdriver wait 1 hour (laugh at me). When I need to test some specific phase, I just add this step where I want Selenium to stop - this leaves browser window open so I can do whatever I want manually without having to fill all previous fields.

It saves a ton of time, but feels stupid. I have reasons to do that:

• Has to be done ASAP.
• I cannot test each separate step in the form.
• I cannot reuse parts of the filling process without having to write quite a lot of PHP code. Now my test is just ~120 lines written in Gherkin language.

Simplified version of my question is: how should I test this?

I can think of several ways:

• Modify the code to allow skipping phases. This can be done safely by detecting environment parameters withing the application and deciding whether client (webdriver or user) can or cannot skip phases, so skipping is not allowed in a production environment.
• Just write more tests with a lot of copy-pasting and be a bigger monkey.

• Write step definitions to complete specific phases separately. So, I could just write

  When I complete phase 1
  And complete phase 2
  And complete phase 3
  ...
  

  in the tests.

So, the full version of my question is: which way is preferable and what (dis)advantages each way has? Maybe there are other ways, like designing an application in a completely different way so there are no such problems.

Answer 1

First off, don't change the code for the convenience of testing. Honestly, that's a case of the tail wagging the dog.

There are some cases where it's justifiable to restructure the code to simplify testing, but for what you've laid out, it's a horrible idea. When you receive a legacy "gift" like this, your first order of business is to change nothing until you can start boxing its effects.

More to your question...

Take an approach of structuring the test steps around the phases of input. We'll pretend that there are business requirements that indicate that the inputs should be received in the fashion you described. (Okay, we know that's a lie, but let's give the benefit of the doubt).

This pretense actually makes it easier to test the code. It's an implied business rule that phase 2 cannot be tested unless phase 1 is complete AND correct. Take a step back and you'll see that this dramatically simplifies the number of scenarios you have to test. Tests within phase 2 can now assume everything is kosher within phase 1 because the business rules say you can't proceed to phase 2 unless 1 is okay.

It sounds like you're taking the right approach to testing things given the constraints you're under. In other words - triage. In an ideal world you could rewrite everything as well as writing perfect test cases at the same time. In the meantime, deadlines are looming and updates need to get shipped. Start with the "heavy hitter" test cases, and add in additional nuances as time allows. This is honestly no different than most other development. Time is generally a luxury that a project cannot afford.

Your ill-at-ease feelings are the conflict between the ideal way of testing the code versus the pragmatic way of testing the code. That's a pretty normal reaction to compromises taken within the development process. Comment the shortcuts you needed to take, indicate the areas to improve, and keep incrementing.

To help with testing later phases, create re-usable sections of mock-up code that complete prior sections correctly. So to test phase 3, you'll make two calls to complete phase 1 and 2 correctly and allow phase 3 to be exposed. It's a smidge of a hack, but it also reflects the business rules involved in the application. In other words, break out your existing single test into 12 components. This will allow you to exercise the downstream phases more easily / independently.