@visualjerk could you help us out on this PR? I'm trying to get rid of
this error:
```
Unknown custom element: <ds-table> - did you register the component
correctly? For recursive components, make sure to provide the "name"
option.
```
How do we tell @vue/test-utils to stub globally registered components?
Second, I don't understand why the resulting html() of the categories
components looks so odd:
```
<h1 class="ds-heading ds-heading-h1" space="small" categories="[object Object],[object Object],[object Object],[object Object],[object Object]">
<h3 class="ds-card"><!----> <!----> <!----> <div class="ds-card-content">
Themen / Kategorien
</div> <!----></h3> <ds-table data="" fields="icon,name,postCount" condensed=""></ds-table></h1>
```
Why on earth does the categories array end up in the `categories`
property of `ds-heading` component?
@visualjerk and @appinteractive have a look, please 😘
We want to run everything, including eslint, from the docker container.
As a next step we would run software tests from the docker container.
Installing the correct version of docker-compose is required, the
default version docker-compose on Travis is older than 3.7.
This misconfiguration doesn't produce a bug without the docker
environment. Better to use docker also for development. Let's make it the
single source of truth.
in `docker-compose.yml` and `docker-compose.override.yml`. This should speed
up builds e.g. on Travis CI, which does not need to sync folders or run
`yarn run dev` if the docker image was built recently. Also it should
make the build more reliable as it behaves more similar to our deployment.
I love cypress already. However my suggestion is to create a separate
repository that includes `backend` and `web` run full stack tests from
there. It is possible to trigger builds in other repositories on Travis
CI. So here is my suggestion: We agree to have matching branch names in
all related repositories, so `branch-1` in repo `web`, `backend` and
`human-connection`.
As a start, the developer has to manually update the submodules in the
meta repository and trigger a build to run fullstack tests. In the
future we might automate this process by triggering builds in other
repos. That's possible on Travis CI, see:
https://docs.travis-ci.com/user/triggering-builds/
See each repository is responsible to keep their set of unit/integration
tests but the meta repository is responsible of carrying out full stack
testing.
@appinteractive your opinion?
