Test suite for Studio

[jamesreprise]

What is the goal of this PR?

In the course of fulfilling https://github.com/vaticle/typedb-studio/issues/392 we have developed a suite of tests concerning the integration of discrete sections of Studio.

Automated testing brings benefits to the future development of Studio: We can be sure before releasing new versions that changes have not broken previous functionality without anyone having to test each of the components and confirm that they work, giving users more confidence in the application.

Developers can now easily add tests to the suite when fixing bugs so that regressions in functionality and error-free use do not arise between releases.

What are the changes implemented in this PR?

We introduce tests for the Project Browser, the Text Editor, the Type Browser and update Quickstart to make use of the interactive methods of writing schemas and data that we've identified during the course of development.

In the course of testing we sometimes manipulate the state directly to bridge small gaps that are left by incomplete parts in the provided test framework from compose-jb. This is seen in our addition of //test/integration:__pkg__ to various BUILD files. It has been agreed that this is acceptable as long as it is the minimum necessary to test.

[grabl]

PR Review Checklist

Do not edit the content of this comment. The PR reviewer should simply update this comment by ticking each review item below, as they get completed.

---

Code

• [x] Packages, classes, and methods have a single domain of responsibility.
• [x] Packages, classes, and methods are grouped into cohesive and consistent domain model.
• [x] The code is canonical and the minimum required to achieve the goal.
• [x] Modules, libraries, and APIs are easy to use, robust (foolproof and not errorprone), and tested.
• [x] Logic and naming has clear narrative that communicates the accurate intent and responsibility of each module (e.g. method, class, etc.).
• [x] The code is algorithmically efficient and scalable for the whole application.

Architecture

• [x] Any required refactoring is completed, and the architecture does not introduce technical debt incidentally.
• [x] Any required build and release automations are updated and/or implemented.
• [x] Any new components follows a consistent style with respect to the pre-existing codebase.
• [x] The architecture intuitively reflects the application domain, and is easy to understand.
• [x] The architecture has a well-defined hierarchy of encapsulated components.
• [x] The architecture is extensible and scalable.

[jamesreprise]

Haven't been able to get this to pass integration tests on CI - marking this as a draft until it passes.

[jamesreprise]

@alexjpwalker I'm marking this as ready for review as I'd like to go through the review checklist and justify my reasons for believing the code is in line with the checklist (with you challenging my decisions). Let me know if you have time for this.

[jamesreprise]

Putting a note here about the test behaviour being flaky - particularly the type browser tests timing out. This doesn't always happen, and it never happens locally.

[jamesreprise]

Based on a discussion Alex and I have had, I don't think we should merge this until the integration tests are more stable in grabl.