[TESTS] Refactor to support database tests via sqlite

[mfn]

Summary

Only "tests" related code has been touched in this PR!

I've already started moving tests into a dedicated namespace

• create new namespace/directory layout for tests and supporting infrastructure
  
• Add a new TestCaseDatabase class which will setup an in-memory SQLITE database and see it with migrations/factories from tests/Support/database
  mainly, we will split tests between pure unit tests (no database required) and ones with

TODO

• Add actual tests using the database, e.g. SelectFields tests
• When endpoint test fails under certain error conditions, they return a regular 404 error page with the exception included in the HTML => this makes debugging harder than it should be
  Will tackle later.

This should pave the way for #277 and #283 so we we'll have proper tests for them.

[zjbarg]

Eventually we need integration tests right?

[mfn]

Eventually we need integration tests right?

Ack, see the TODO ;-)

[mfn]

This test shows the functionality with SelectFields \o/

[rebing]

Nice

[rebing]

Shouldn't this (and the other Queries as well) return Type::nonNull(GraphQL::type('Post')) instead?

[rebing]

Ok nvm, I just saw the issue you posted. It's strange though, because I thought I've used nonNull with custom types

[zjbarg]

Whats the issue with indenting this?

[mfn]

What do you mean specifically?

[zjbarg]

Whats the issue with indenting this?

[mfn]

Can you elaborate?

[zjbarg]

its kinda painful to work this way! My editor went mad!
Image

[mfn]

Hmm, works correctly for me => using PhpStorm 2019 here; what IDE are you using?

The issue I'm seeing:

• it doesn't matter for the GraphQL queries (whitespace is insignificant)
• but for the SQL assertion/comparison, they are significant

Another reason I like to keep it this way is, especially for the SQL assertions, they can get very long. Inevitably horizontal scrolling for them will be necessary often, but the less that is required, the better.

[rebing]

Nice work! The assertSqlQueries solution is cool.

[mfn]

The assertSqlQueries solution is cool.

Thanks!

I don't see this approach used very often. I've been working on commercial projects where, under complex circumstances, it's necessary to understand the SQL code being executed (selected columns, n+1 problems, redundant queries, …).
n+1 problems can sometimes also easily be spotted via just assertion the counts by seeing the actual statements it's very insightful.

Especially in this case where the entire goal of SelectFields is about custom queries, I though the only way to assert the correct is about the SQL statements.