Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adaptors tests #167

Closed
mtuchi opened this issue Nov 17, 2022 · 4 comments
Closed

Adaptors tests #167

mtuchi opened this issue Nov 17, 2022 · 4 comments
Labels
tooling Related to the builds and tooling

Comments

@mtuchi
Copy link
Collaborator

mtuchi commented Nov 17, 2022

Description

During the process of migration, we skipped a lot of tests that are failing. We should have a tests mock framework to make the process of writing test easy in adaptors.

Currently most of the tests in adaptors are quite similar, and this doesn't seem quite right, because the way an adaptor is being tested depends on the system that adaptor is for. For example if the adaptor is for a REST API then maybe mocking with libs like sinon is the way to go but if the adaptor is for a database then we should have defined database sandboxes to do integration tests, etc.

There are also some helper functions that are being re-tested like execute while they have already been tested in another adaptor.

@taylordowns2000 we do think that there should be an interesting discussion around the way adaptors are being tested currently and maybe an outcome of that discussion will be defining patterns, tools, strategies, ..., for testing adaptors.

@taylordowns2000
Copy link
Member

I'd say we want to have a separate PASS/FAIL status for each adaptor in the /packages directory. From a CI perspetive, this might mean that we configure circle to recurse through all directories inside /packages and run pnpm test for each, outputting the results individually.

@mtuchi mtuchi mentioned this issue May 24, 2023
4 tasks
@josephjclark
Copy link
Collaborator

  1. Identify which adaptors need better tests and WHY
  2. Work out a way to test job DSL code properly (including composability)
  3. Establish good conventions for mocking dbs (I think nock is fine for http tests?)

@josephjclark josephjclark added the tooling Related to the builds and tooling label Jun 8, 2023
@taylordowns2000 taylordowns2000 moved this to Icebox in v2 Feb 3, 2024
@mtuchi
Copy link
Collaborator Author

mtuchi commented Mar 21, 2024

I think we should close this and create issues for individual adaptors [Preferably our top 5 adaptors]. This might be a good transition to testing mockable operations
cc @josephjclark

@josephjclark
Copy link
Collaborator

Yeah I kinda agre

I think the mockable operations stuff needs to happen first and we don't really have an issue for it.

We already have issue for some problematic tests.

I don't think this issue has intrinisic value, but I don't think we should create new issues unless we absolutely need it.

Maybe when the mocking stuff is done and merged, we can raise some good first issue tickets to expand the tests on the top 5. But let's not bother for now.

@github-project-automation github-project-automation bot moved this from Icebox to Done in v2 Mar 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
tooling Related to the builds and tooling
Projects
Archived in project
Development

No branches or pull requests

3 participants