You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As the current state of #18 unit testing is rather minimal, we should likely consider investing more effort in establishing a reasonable, locally-replicable integration testing approach.
Practically, if this task came to me to develop and maintain, I would, somewhat unsurprisingly, choose rfjl, and can get reports into the CI pipeline (#30) quite rapidly. I typically maintain at least the test environment in heavily-locked-down conda environments, since I don't like surprises, but this has no bearing on what the system-under-test runs in.
An additional wrinkle: we don't have a real backend we can test. It may be worth considering an easily self-hostable, but real backend (a la gitea on sqlite) rather than mocking github/gitlab. gitea is also available from conda-forge, but somewhat old at this point.
galata is probably gonna be the integration tool in the long run. But I have no experience on neither galata or robotframework.
Regarding galata, I use playwright quite often lately and the most efficient way I found to create test was to use the code generation feature. So basically one will not start that from JupyterLab anyway...
Regarding third-party service mock, I experimented mock-server lately. It can create expectations from open-api specification or by recording usage.
As the current state of #18 unit testing is rather minimal, we should likely consider investing more effort in establishing a reasonable, locally-replicable integration testing approach.
Options
jupyterlab-lsp
makes this.... better, but js/ts have lots of sharp edges)robotkernel
orxeus-robot
The text was updated successfully, but these errors were encountered: