refactor(tests): Make Integration tests dynamic and Json Snapshot Based.

[oreenlivnicode]

Created organization - RavenIntegrationTests. It will contain only the repositories we want to test.

Refactor the way we test integrations.
We will have a snapshot json file under tests/integration/structures_json/ of the neo4j structure.
To test all the relationships and node properties as expected, we will convert graph objects to json structure using utilities I've added and compare it to the snapshot object.
It will assert every node/relationship remains the same.

This allows us to scale up our tests, and to test complex scenarios with no effort.
This is an example of snapshot file

{
"nodes": [{
"path": "actions/checkout",
"using": "node20",
"inputs": ["repository", "ref", "token", "ssh-key", "ssh-known-hosts", "ssh-strict", "persist-credentials", "path", "clean", "filter", "sparse-checkout", "sparse-checkout-cone-mode", "fetch-depth", "fetch-tags", "show-progress", "lfs", "submodules", "set-safe-directory", "github-server-url"],
"name": "Checkout",
"is_public": true,
"_id": "d35e7df441120da9624b8c11e36151be",
"url": "https://github.com/actions/checkout/tree/main/action.yml",
"labels": ["CompositeAction"]
},
],
"relationships": [{
"start_node": "83b34c58d9a3220059a67e3671ff97f2",
"type": "ACTION",
"end_node": "d35e7df441120da9624b8c11e36151be"
},
]
}

[elad-pticha]

LGTM!

Can we get a docs from this? Let's start documenting things like this under wiki/other solution.

Now, for each request, we require contributors to add tests, and we need that process to be fully understood.

[alex-ilgayev]

Looks great!
This will be a great improvement for our CI process. Great job!
I left few comments, summarizing them:

• I suggest leaving test_node_count.py for now until this solution will be more mature and tested. Because otherwise we don't have any integrations tests for PRs. Same for the test_pr.yml workflow.
• We need to think how adding integration tests would be the minimum code addition as possible. In my mind that would be adding/modifying a JSON, and referencing it in the test_graph_structures.py. I would think how to remove completely the integration_consts.py, and do a single loop that goes over all integration tests.
• To have clear feature coverage, we need to understand the coverage for each integration test we have. Few lines per test would be great.
• And finally, as Elad said, we need to provide simple guidance for adding new tests.
  Great job overall!

[oreenlivnicode]

@alex-ilgayev@elad-pticha - Check out new integration_consts.py structure.
The test_graph_structures.py file is set up to have a single, generic test that can be used across various integration tests.

Alternatively, we could break down the configuration dictionaries and include each specific configuration in its corresponding JSON structure file. This way, the configuration for a given test would be retrieved directly from its associated JSON file.

[oreenlivnicode]

Created organization - RavenIntegrationTests. It will contain only the repositories we want to test.

Refactor the way we test integrations.
We will have a snapshot json file under tests/integration/structures_json/ of the neo4j structure.
To test all the relationships and node properties as expected, we will convert graph objects to json structure using utilities I've added and compare it to the snapshot object.
It will assert every node/relationship remains the same.

This allows us to scale up our tests, and to test complex scenarios with no effort.
This is an example of snapshot file

{
"nodes": [{
"path": "actions/checkout",
"using": "node20",
"inputs": ["repository", "ref", "token", "ssh-key", "ssh-known-hosts", "ssh-strict", "persist-credentials", "path", "clean", "filter", "sparse-checkout", "sparse-checkout-cone-mode", "fetch-depth", "fetch-tags", "show-progress", "lfs", "submodules", "set-safe-directory", "github-server-url"],
"name": "Checkout",
"is_public": true,
"_id": "d35e7df441120da9624b8c11e36151be",
"url": "https://github.com/actions/checkout/tree/main/action.yml",
"labels": ["CompositeAction"]
},
],
"relationships": [{
"start_node": "83b34c58d9a3220059a67e3671ff97f2",
"type": "ACTION",
"end_node": "d35e7df441120da9624b8c11e36151be"
},
]
}

[elad-pticha]

LGTM!

Can we get a docs from this? Let's start documenting things like this under wiki/other solution.

Now, for each request, we require contributors to add tests, and we need that process to be fully understood.

[alex-ilgayev]

Looks great!
This will be a great improvement for our CI process. Great job!
I left few comments, summarizing them:

• I suggest leaving test_node_count.py for now until this solution will be more mature and tested. Because otherwise we don't have any integrations tests for PRs. Same for the test_pr.yml workflow.
• We need to think how adding integration tests would be the minimum code addition as possible. In my mind that would be adding/modifying a JSON, and referencing it in the test_graph_structures.py. I would think how to remove completely the integration_consts.py, and do a single loop that goes over all integration tests.
• To have clear feature coverage, we need to understand the coverage for each integration test we have. Few lines per test would be great.
• And finally, as Elad said, we need to provide simple guidance for adding new tests.
  Great job overall!

[oreenlivnicode]

@alex-ilgayev@elad-pticha - Check out new integration_consts.py structure.
The test_graph_structures.py file is set up to have a single, generic test that can be used across various integration tests.

Alternatively, we could break down the configuration dictionaries and include each specific configuration in its corresponding JSON structure file. This way, the configuration for a given test would be retrieved directly from its associated JSON file.

[oreenlivnicode]

Created organization - RavenIntegrationTests. It will contain only the repositories we want to test.

Refactor the way we test integrations.
We will have a snapshot json file under tests/integration/structures_json/ of the neo4j structure.
To test all the relationships and node properties as expected, we will convert graph objects to json structure using utilities I've added and compare it to the snapshot object.
It will assert every node/relationship remains the same.

This allows us to scale up our tests, and to test complex scenarios with no effort.
This is an example of snapshot file

{
"nodes": [{
"path": "actions/checkout",
"using": "node20",
"inputs": ["repository", "ref", "token", "ssh-key", "ssh-known-hosts", "ssh-strict", "persist-credentials", "path", "clean", "filter", "sparse-checkout", "sparse-checkout-cone-mode", "fetch-depth", "fetch-tags", "show-progress", "lfs", "submodules", "set-safe-directory", "github-server-url"],
"name": "Checkout",
"is_public": true,
"_id": "d35e7df441120da9624b8c11e36151be",
"url": "https://github.com/actions/checkout/tree/main/action.yml",
"labels": ["CompositeAction"]
},
],
"relationships": [{
"start_node": "83b34c58d9a3220059a67e3671ff97f2",
"type": "ACTION",
"end_node": "d35e7df441120da9624b8c11e36151be"
},
]
}

[elad-pticha]

LGTM!

Can we get a docs from this? Let's start documenting things like this under wiki/other solution.

Now, for each request, we require contributors to add tests, and we need that process to be fully understood.

[alex-ilgayev]

Looks great!
This will be a great improvement for our CI process. Great job!
I left few comments, summarizing them:

• I suggest leaving test_node_count.py for now until this solution will be more mature and tested. Because otherwise we don't have any integrations tests for PRs. Same for the test_pr.yml workflow.
• We need to think how adding integration tests would be the minimum code addition as possible. In my mind that would be adding/modifying a JSON, and referencing it in the test_graph_structures.py. I would think how to remove completely the integration_consts.py, and do a single loop that goes over all integration tests.
• To have clear feature coverage, we need to understand the coverage for each integration test we have. Few lines per test would be great.
• And finally, as Elad said, we need to provide simple guidance for adding new tests.
  Great job overall!

[oreenlivnicode]

@alex-ilgayev@elad-pticha - Check out new integration_consts.py structure.
The test_graph_structures.py file is set up to have a single, generic test that can be used across various integration tests.

Alternatively, we could break down the configuration dictionaries and include each specific configuration in its corresponding JSON structure file. This way, the configuration for a given test would be retrieved directly from its associated JSON file.

[oreenlivnicode]

Created organization - RavenIntegrationTests. It will contain only the repositories we want to test.

Refactor the way we test integrations.
We will have a snapshot json file under tests/integration/structures_json/ of the neo4j structure.
To test all the relationships and node properties as expected, we will convert graph objects to json structure using utilities I've added and compare it to the snapshot object.
It will assert every node/relationship remains the same.

This allows us to scale up our tests, and to test complex scenarios with no effort.
This is an example of snapshot file

{
"nodes": [{
"path": "actions/checkout",
"using": "node20",
"inputs": ["repository", "ref", "token", "ssh-key", "ssh-known-hosts", "ssh-strict", "persist-credentials", "path", "clean", "filter", "sparse-checkout", "sparse-checkout-cone-mode", "fetch-depth", "fetch-tags", "show-progress", "lfs", "submodules", "set-safe-directory", "github-server-url"],
"name": "Checkout",
"is_public": true,
"_id": "d35e7df441120da9624b8c11e36151be",
"url": "https://github.com/actions/checkout/tree/main/action.yml",
"labels": ["CompositeAction"]
},
],
"relationships": [{
"start_node": "83b34c58d9a3220059a67e3671ff97f2",
"type": "ACTION",
"end_node": "d35e7df441120da9624b8c11e36151be"
},
]
}

[elad-pticha]

LGTM!

Can we get a docs from this? Let's start documenting things like this under wiki/other solution.

Now, for each request, we require contributors to add tests, and we need that process to be fully understood.

[alex-ilgayev]

Looks great!
This will be a great improvement for our CI process. Great job!
I left few comments, summarizing them:

• I suggest leaving test_node_count.py for now until this solution will be more mature and tested. Because otherwise we don't have any integrations tests for PRs. Same for the test_pr.yml workflow.
• We need to think how adding integration tests would be the minimum code addition as possible. In my mind that would be adding/modifying a JSON, and referencing it in the test_graph_structures.py. I would think how to remove completely the integration_consts.py, and do a single loop that goes over all integration tests.
• To have clear feature coverage, we need to understand the coverage for each integration test we have. Few lines per test would be great.
• And finally, as Elad said, we need to provide simple guidance for adding new tests.
  Great job overall!

[oreenlivnicode]

@alex-ilgayev@elad-pticha - Check out new integration_consts.py structure.
The test_graph_structures.py file is set up to have a single, generic test that can be used across various integration tests.

Alternatively, we could break down the configuration dictionaries and include each specific configuration in its corresponding JSON structure file. This way, the configuration for a given test would be retrieved directly from its associated JSON file.

[oreenlivnicode]

Created organization - RavenIntegrationTests. It will contain only the repositories we want to test.

Refactor the way we test integrations.
We will have a snapshot json file under tests/integration/structures_json/ of the neo4j structure.
To test all the relationships and node properties as expected, we will convert graph objects to json structure using utilities I've added and compare it to the snapshot object.
It will assert every node/relationship remains the same.

This allows us to scale up our tests, and to test complex scenarios with no effort.
This is an example of snapshot file

{
"nodes": [{
"path": "actions/checkout",
"using": "node20",
"inputs": ["repository", "ref", "token", "ssh-key", "ssh-known-hosts", "ssh-strict", "persist-credentials", "path", "clean", "filter", "sparse-checkout", "sparse-checkout-cone-mode", "fetch-depth", "fetch-tags", "show-progress", "lfs", "submodules", "set-safe-directory", "github-server-url"],
"name": "Checkout",
"is_public": true,
"_id": "d35e7df441120da9624b8c11e36151be",
"url": "https://github.com/actions/checkout/tree/main/action.yml",
"labels": ["CompositeAction"]
},
],
"relationships": [{
"start_node": "83b34c58d9a3220059a67e3671ff97f2",
"type": "ACTION",
"end_node": "d35e7df441120da9624b8c11e36151be"
},
]
}

[elad-pticha]

LGTM!

Can we get a docs from this? Let's start documenting things like this under wiki/other solution.

Now, for each request, we require contributors to add tests, and we need that process to be fully understood.

[alex-ilgayev]

Looks great!
This will be a great improvement for our CI process. Great job!
I left few comments, summarizing them:

• I suggest leaving test_node_count.py for now until this solution will be more mature and tested. Because otherwise we don't have any integrations tests for PRs. Same for the test_pr.yml workflow.
• We need to think how adding integration tests would be the minimum code addition as possible. In my mind that would be adding/modifying a JSON, and referencing it in the test_graph_structures.py. I would think how to remove completely the integration_consts.py, and do a single loop that goes over all integration tests.
• To have clear feature coverage, we need to understand the coverage for each integration test we have. Few lines per test would be great.
• And finally, as Elad said, we need to provide simple guidance for adding new tests.
  Great job overall!

[oreenlivnicode]

@alex-ilgayev@elad-pticha - Check out new integration_consts.py structure.
The test_graph_structures.py file is set up to have a single, generic test that can be used across various integration tests.

Alternatively, we could break down the configuration dictionaries and include each specific configuration in its corresponding JSON structure file. This way, the configuration for a given test would be retrieved directly from its associated JSON file.

[oreenlivnicode]

Created organization - RavenIntegrationTests. It will contain only the repositories we want to test.

Refactor the way we test integrations.
We will have a snapshot json file under tests/integration/structures_json/ of the neo4j structure.
To test all the relationships and node properties as expected, we will convert graph objects to json structure using utilities I've added and compare it to the snapshot object.
It will assert every node/relationship remains the same.

This allows us to scale up our tests, and to test complex scenarios with no effort.
This is an example of snapshot file

{
"nodes": [{
"path": "actions/checkout",
"using": "node20",
"inputs": ["repository", "ref", "token", "ssh-key", "ssh-known-hosts", "ssh-strict", "persist-credentials", "path", "clean", "filter", "sparse-checkout", "sparse-checkout-cone-mode", "fetch-depth", "fetch-tags", "show-progress", "lfs", "submodules", "set-safe-directory", "github-server-url"],
"name": "Checkout",
"is_public": true,
"_id": "d35e7df441120da9624b8c11e36151be",
"url": "https://github.com/actions/checkout/tree/main/action.yml",
"labels": ["CompositeAction"]
},
],
"relationships": [{
"start_node": "83b34c58d9a3220059a67e3671ff97f2",
"type": "ACTION",
"end_node": "d35e7df441120da9624b8c11e36151be"
},
]
}

[elad-pticha]

LGTM!

Can we get a docs from this? Let's start documenting things like this under wiki/other solution.

Now, for each request, we require contributors to add tests, and we need that process to be fully understood.

[alex-ilgayev]

Looks great!
This will be a great improvement for our CI process. Great job!
I left few comments, summarizing them:

• I suggest leaving test_node_count.py for now until this solution will be more mature and tested. Because otherwise we don't have any integrations tests for PRs. Same for the test_pr.yml workflow.
• We need to think how adding integration tests would be the minimum code addition as possible. In my mind that would be adding/modifying a JSON, and referencing it in the test_graph_structures.py. I would think how to remove completely the integration_consts.py, and do a single loop that goes over all integration tests.
• To have clear feature coverage, we need to understand the coverage for each integration test we have. Few lines per test would be great.
• And finally, as Elad said, we need to provide simple guidance for adding new tests.
  Great job overall!

[oreenlivnicode]

@alex-ilgayev@elad-pticha - Check out new integration_consts.py structure.
The test_graph_structures.py file is set up to have a single, generic test that can be used across various integration tests.

Alternatively, we could break down the configuration dictionaries and include each specific configuration in its corresponding JSON structure file. This way, the configuration for a given test would be retrieved directly from its associated JSON file.

[oreenlivnicode]

Created organization - RavenIntegrationTests. It will contain only the repositories we want to test.

Refactor the way we test integrations.
We will have a snapshot json file under tests/integration/structures_json/ of the neo4j structure.
To test all the relationships and node properties as expected, we will convert graph objects to json structure using utilities I've added and compare it to the snapshot object.
It will assert every node/relationship remains the same.

This allows us to scale up our tests, and to test complex scenarios with no effort.
This is an example of snapshot file

{
"nodes": [{
"path": "actions/checkout",
"using": "node20",
"inputs": ["repository", "ref", "token", "ssh-key", "ssh-known-hosts", "ssh-strict", "persist-credentials", "path", "clean", "filter", "sparse-checkout", "sparse-checkout-cone-mode", "fetch-depth", "fetch-tags", "show-progress", "lfs", "submodules", "set-safe-directory", "github-server-url"],
"name": "Checkout",
"is_public": true,
"_id": "d35e7df441120da9624b8c11e36151be",
"url": "https://github.com/actions/checkout/tree/main/action.yml",
"labels": ["CompositeAction"]
},
],
"relationships": [{
"start_node": "83b34c58d9a3220059a67e3671ff97f2",
"type": "ACTION",
"end_node": "d35e7df441120da9624b8c11e36151be"
},
]
}

[elad-pticha]

LGTM!

Can we get a docs from this? Let's start documenting things like this under wiki/other solution.

Now, for each request, we require contributors to add tests, and we need that process to be fully understood.

[alex-ilgayev]

Looks great!
This will be a great improvement for our CI process. Great job!
I left few comments, summarizing them:

• I suggest leaving test_node_count.py for now until this solution will be more mature and tested. Because otherwise we don't have any integrations tests for PRs. Same for the test_pr.yml workflow.
• We need to think how adding integration tests would be the minimum code addition as possible. In my mind that would be adding/modifying a JSON, and referencing it in the test_graph_structures.py. I would think how to remove completely the integration_consts.py, and do a single loop that goes over all integration tests.
• To have clear feature coverage, we need to understand the coverage for each integration test we have. Few lines per test would be great.
• And finally, as Elad said, we need to provide simple guidance for adding new tests.
  Great job overall!

[oreenlivnicode]

@alex-ilgayev@elad-pticha - Check out new integration_consts.py structure.
The test_graph_structures.py file is set up to have a single, generic test that can be used across various integration tests.

Alternatively, we could break down the configuration dictionaries and include each specific configuration in its corresponding JSON structure file. This way, the configuration for a given test would be retrieved directly from its associated JSON file.

[oreenlivnicode]

Created organization - RavenIntegrationTests. It will contain only the repositories we want to test.

Refactor the way we test integrations.
We will have a snapshot json file under tests/integration/structures_json/ of the neo4j structure.
To test all the relationships and node properties as expected, we will convert graph objects to json structure using utilities I've added and compare it to the snapshot object.
It will assert every node/relationship remains the same.

This allows us to scale up our tests, and to test complex scenarios with no effort.
This is an example of snapshot file

{
"nodes": [{
"path": "actions/checkout",
"using": "node20",
"inputs": ["repository", "ref", "token", "ssh-key", "ssh-known-hosts", "ssh-strict", "persist-credentials", "path", "clean", "filter", "sparse-checkout", "sparse-checkout-cone-mode", "fetch-depth", "fetch-tags", "show-progress", "lfs", "submodules", "set-safe-directory", "github-server-url"],
"name": "Checkout",
"is_public": true,
"_id": "d35e7df441120da9624b8c11e36151be",
"url": "https://github.com/actions/checkout/tree/main/action.yml",
"labels": ["CompositeAction"]
},
],
"relationships": [{
"start_node": "83b34c58d9a3220059a67e3671ff97f2",
"type": "ACTION",
"end_node": "d35e7df441120da9624b8c11e36151be"
},
]
}

[elad-pticha]

LGTM!

Can we get a docs from this? Let's start documenting things like this under wiki/other solution.

Now, for each request, we require contributors to add tests, and we need that process to be fully understood.

[alex-ilgayev]

Looks great!
This will be a great improvement for our CI process. Great job!
I left few comments, summarizing them:

• I suggest leaving test_node_count.py for now until this solution will be more mature and tested. Because otherwise we don't have any integrations tests for PRs. Same for the test_pr.yml workflow.
• We need to think how adding integration tests would be the minimum code addition as possible. In my mind that would be adding/modifying a JSON, and referencing it in the test_graph_structures.py. I would think how to remove completely the integration_consts.py, and do a single loop that goes over all integration tests.
• To have clear feature coverage, we need to understand the coverage for each integration test we have. Few lines per test would be great.
• And finally, as Elad said, we need to provide simple guidance for adding new tests.
  Great job overall!

[oreenlivnicode]

@alex-ilgayev@elad-pticha - Check out new integration_consts.py structure.
The test_graph_structures.py file is set up to have a single, generic test that can be used across various integration tests.

Alternatively, we could break down the configuration dictionaries and include each specific configuration in its corresponding JSON structure file. This way, the configuration for a given test would be retrieved directly from its associated JSON file.