Toolkit for building smart answers. Have a look at
test/unit/flow_test.rb for example usage.
This application supports two styles of writing and executing smart answers:
Ruby and YAML-based smart answer flows
For more information, please go to the Ruby/YAML SmartAnswer README
Smartdown-based smart answer flows
For more information, please go to the Smartdown SmartAnswer README
Switching from one style to another
Smart answers are by default expected to be in Ruby/YAML style.
To transition a smart answer from Ruby/YML to Smartdown style, register it in the smartdown registry (lib/smartdown/registry.rb).
Debugging current state
If you have a URL of a Smart answer and want to debug the state of it i.e. to see PhraseList keys, saved inputs, the outcome name, append debug=1 query parameter to the URL in development mode. This will render debug information on the Smart answer page.
Visualising a flow
To see a visualisation of a smart answer flow, append /visualise to the root of a smartanswer URL e.g. http://smartanswers.dev.gov.uk/<my-flow>/visualise/
NB: this assumes you are running on the GOV.UK virtual machine, not your host.
./install # git fetch from each dependency dir and bundle installRun using bowler on VM from cd /var/govuk/development:
bowl smartanswers
To view a smart answer locally if running using bowler http://smartanswers.dev.gov.uk/register-a-birth
Run unit tests by executing the following:
bundle exec rake
** Fixtures **
If you need to add a new worldwide organisations fixture find it here, navigate to <found_url>.json, most likely it will be of the following format https://www.gov.uk/api/world/organisations/british-[embassy|high-commission]-<capital city>, copy over the JSON to test/fixtures/worldwide/<country>_organisations.json and change it to reflect the expected format based on other examples in the directory.
Please see the github issues page.
When making bigger changes that need to be tested before they go live it is best to release them as a draft first. There is a rake task for creating a draft flow rake version:v2[flow]. This is not ideal, but it allows to check the changes in the UI in the development and preview environments without affecting the production environment.
Once reviewed, the draft can be published by running rake version:publish[flow]. This merges V2 changes into the original files. Take a look at the rake task to see the details. If you used any other V2 files that are not covered by the rake task, make sure to process them manually.
Commiting V2 -> V1 changes
To help developers track changes in files easily, it is best if you commit V2 files' removal in one commit, then commit the modifications to the original files. This creates an easy to browse diff of all the changes being published. Write a descriptive message for the second commit, as this is what the other developers will see in the file history.