Fix intermittent failing tests

[oscarwyatt]

Improves further on PR #1052. Moved custom configuration to a before_initialize block which seems to solve a problem with the config not being available in test environment. Based on the following stackoverflow post

https://stackoverflow.com/a/44770663

Trello: https://trello.com/c/toblYkmD/133-investigate-and-fix-failing-tests-on-government-frontend

---

Visual regression results:
https://government-frontend-pr-1057.surge.sh/gallery.html

Component guide for this PR:
https://government-frontend-pr-1057.herokuapp.com/component-guide

[vanitabarrett]

@oscarwyatt Not sure this is resolved - still getting the same errors, e.g:

[build] Failure:
[build] LinksOutConfigTest#test_links_out_configuration_causes_no_errors_and_correct_supergroups_are_displayed_for_each_ruleset [/var/lib/jenkins/workspace/intermittently-failing-test-IAOZESY5I7JDI3LIV3SCFYLXHQ4CKM4DHPPJL6OA4VBZIDUKB4CA/test/integration/links_out_config_test.rb:60]:
[build] Expected false to be truthy.

and

[build] Error:
[build] LinksOutConfigTest#test_links_out_configuration_causes_no_errors_and_correct_supergroups_are_displayed_for_each_ruleset:
[build] NoMethodError: undefined method `each_key' for nil:NilClass
[build]     test/integration/links_out_config_test.rb:56:in `block (3 levels) in <class:LinksOutConfigTest>'
[build]     test/integration/links_out_config_test.rb:55:in `each_key'
[build]     test/integration/links_out_config_test.rb:55:in `block (2 levels) in <class:LinksOutConfigTest>'
[build]     test/integration/links_out_config_test.rb:54:in `block in <class:LinksOutConfigTest>'
[build] 
[build] bin/rails test test/integration/links_out_config_test.rb:51

I've been taking a look this afternoon too, but haven't managed to make any progress on it. I think if we still don't have a solution tomorrow we should probably remove this test for now so we're not slowing other people down in government-frontend (as it's updated quite often). We can add it back in when we're confident it's working 🙂

[oscarwyatt]

@vanitabarrett I think you're probably right.
According to the rails source, there are some situations in which config_for will return a blank hash
`# File railties/lib/rails/application.rb, line 227
def config_for(name)
yaml = Pathname.new("#{paths["config"].existent.first}/#{name}.yml")

  if yaml.exist?
    require "erb"
    (YAML.load(ERB.new(yaml.read).result) || {})[Rails.env] || {}
  else
    raise "Could not load configuration. No such file - #{yaml}"
  end
rescue Psych::SyntaxError => e
  raise "YAML syntax error occurred while parsing #{yaml}. "          "Please note that YAML must be consistently indented using spaces. Tabs are not allowed. "          "Error: #{e.message}"
end`

Although it's not exactly clear why this is happening in CI. I've made an amendment to load the file directly from source, which isn't ideal as someone could come along and change which file is used. If this still isn't working I'm happy for you to get rid of it and I'll try and think of a better way of testing the config file

[andrewgarner]

@vanitabarrett @oscarwyatt I've made some changes that I hope will help this:

1. I've made it so we actually stub the Rails configuration object not modify it under test. This is to ensure we don't accidentally break the application which I think could have happened with randomly ordered tests.

2. I've rewritten the config test so that the tests are dynamically generated based on the contents of the config file. This means that each test only has to make one browser request and a couple of assertions. Hopefully that makes timeouts less likely. Hopefully it is also a bit easier to comprehend.

I've added alternative commits

[vanitabarrett]

Changes look good 👍 Rebuilt a few times and all passed too