ui: Repo layer integration tests for methods that touch the API
Includes a `repo` test helper to make repetitive tasks easier, plus a
injectable reporter for sending performance metrics to a centralized metrics
system
Also noticed somewhere in the ember models that I'd like to improve, but left
for the moment to make sure I concentrate on one task at a time, more or less:
The tests currently asserts against the existing JSON tree, which doesn't
seem to be a very nice tree.
The work at hand here is to refactor what is there, so test for the not
nice tree to ensure we don't get any regression, and add a skipped test
so I can come back here later
WIP Unskip some lower level trivial tests.
This is the beginning of work to unskip some of the more trivial tests that I'd skipped a while back (if the thing they are testing broke, they would have failed higher up in other acceptance tests).
I'd rather keep the tests, as they do test things in a more isolated manner, and the plan was to always come back and work to unskip them time allowing.
I didn't get to far into this work in progress here, but I'd rather merge what I've done all the same and come back at a later date and continue.
1. Split the resizing functionality of into a separate mixin to be
shared across components
2. Add basic integration tests to prove that everything is getting
called through out the lifetime of the app. I decided against unit
testing as there isn't really any isolated logic to be tested, more
checking that things are being called in the correct order etc i.e. the
integration is correct.
Adds assertion to with-resizing so its obvious to override `resize`
Adds additional 'enterprise' text underneath the 'startup' logo if the
ui is built with a CONSUL_BINARY_TYPE environment variable that doesn't
equal `oss`.
* Add some tests to check the correct GET API endpoints are called
* Refactor adapters
1. Add integration tests for `urlFor...` and majority `handleResponse` methods
2. Refactor out `handleResponse` a little more into single/batch/boolean
methods
3. Move setting of the `Datacenter` property into the `handleResponse`
method, basically the same place that the uid is being set using the dc
parsed form the URL
4. Add some Errors for if you don't pass ids to certain `urlFor` methods
1. In the Services > Services detail page for both healthy and unhealthy
nodes, also add searching by Service.ID here
2. In the Nodes > Node detail > [Services] tab only if its different
from the Service name, add searching by Service.ID here
We now essentially do 2 redirects if you hit a `folder/`
1. If you visit `/ui/dc1/kv/folder/`, `consul` will redirect you to `/ui/dc1/kv/folder`
2. Once redirected to `/ui/dc1/kv/folder` via a 301, use ember/history
API to redirect you back to `/ui/dc1/kv/folder/`.
Bit long winded, but achieves what we want without having to get stuck
into `consul` itself to remove the 301 for the UI
The Consul API can pass through `Value: null` which does not get cast to
a string by ember-data. This snowballs into problems with `atob` which
then tried to decode `null`.
There are 2 problems here.
1. `Value` should never be `null`
- I've added a removeNull function to shallowly loop though props and
remove properties that are `null`, for the moment this is only on
single KV JSON responses - therefore `Value` will never be `null`
which is the root of the problem
2. `atob` doesn't quite follow the `window.atob` API in that the
`window.atob` API casts everything down to a string first, therefore it
will try to decode `null` > `'null'` > `crazy unicode thing`.
- I've commented in a fix for this, but whilst this shouldn't be
causing anymore problems in our UI (now that `Value` is never `null`),
I'll uncomment it in another future release. Tests are already written
for it which more closely follow `window.atob` but skipped for now
(next commit)
1. There are various things tests that can just have intentions added
into them, like filters and such like, add intentions to these
2. Start thinking about being able to negate steps easily, which will
lead on to a cleanup of the steps
This enables people to enter things using the mouse to paste for
example, plus possible other things.
As an aside it also answers my query regarding `fillIn` for testing,
nothing needs to be actually _typed_ anymore! Doh
Previously `api-double` usage in ember would require a bunch of `fetch`
requests to pull in the 'api double', this had a number of disadvantages.
1. The doubles needed to be available via HTTP, which meant a short term
solution of rsyncing the double files over to `public` in order to be served
over HTTP. An alternative to that would have been figuring out how to serve
something straight from `node_modules`, which would have been preferable.
2. ember/testem would not serve dot files (so anything starting with a
., like `.config`. To solve this via ember/testem would have involved
digging in to understand how to enable the serving of dot files.
3. ember/testem automatically rewrote urls for non-existant files to
folders, i.e. adding a slash for you, so `/v1/connect/intentions` would
be rewritten to `/v1/connect/intentions/`. This is undesirable, and
solving this via ember/testem would have involved digging deep to
disable that.
Serving the files via HTTP has now changed. The double files are now
embedded into the HTML has 'embedded templates' that can be found by
using the url of the file and a simple `querySelector`. This of course
only happens during testing and means I can fully control the 'serving'
of the doubles now, so I can say goodbye to the need to move files
around, worry about the need to serve dotfiles and the undesirable
trailing slashes rewriting. Winner!
Find the files and embedding them is done using a straightforward
recursive-readdir-sync (the `content-for` functionality is a synchronous
api) as oppose to getting stuck into `broccoli`.
1. Use 'All Services (*)' as opposed to '*'
2. Set 'Destination' in teh same bold font as 'Source'
3. Ensure you can search for all services by using '*' or 'All Services
(*)'
1. Listing, filtering by action and searching by source name and
destination name
2. Edit/Create page, edits ping the API double fine, need to work through
creates and deletes
3. Currently uses a `Precedence` intention keyname that doesn't yet
exist in the real API
1. Check the dc's model for both dcs list and the requested dc.
2. If the dc model doesn't exist use and empty array for dcs and a fake
dc with the Name 'Error' as we can't even trust what is in the
`paramsFor`
John Cowen