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

Figure out an end-to-end testing approach #63

Open
hbagdi opened this issue Aug 20, 2019 · 4 comments
Open

Figure out an end-to-end testing approach #63

hbagdi opened this issue Aug 20, 2019 · 4 comments
Labels

Comments

@hbagdi
Copy link
Member

hbagdi commented Aug 20, 2019

decK v0.5.0 had a very simple bug that rendered the release unusable.
This could have been easily could with an automated end-to-end testing setup, which we don't have at the moment.
As more changes are introduced, manual testing is becoming more expesive and proving not to be sufficient.
Figure out a path forward for how do we want to test decK in an automated fashion.

@teunis90
Copy link

teunis90 commented Feb 7, 2020

Going over your open tickets, I saw this one.

What about creating a full-featured kong.yaml file, provision Kong:

  • Dump the kong file, and diff
  • Call all HTTP endpoints manually.

That would not cover everything but would be a good start.

@hbagdi
Copy link
Member Author

hbagdi commented Feb 7, 2020

That will cover part of it but not all. We need to test that decK is smart enough to handle cases where it can detect differences and out of sync cases, do reverse syncs too.

If you wish to contribute what you are suggesting, that would be a good addition. PR welcome!

@hbagdi hbagdi added the testing label Jul 14, 2020
@hbagdi hbagdi removed their assignment Mar 7, 2021
@stale
Copy link

stale bot commented Mar 21, 2021

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale Will be closed unless advocated for within 7 days label Mar 21, 2021
@stale stale bot closed this as completed Mar 28, 2021
@hbagdi hbagdi reopened this Mar 29, 2021
@stale stale bot removed the stale Will be closed unless advocated for within 7 days label Mar 29, 2021
@hbagdi
Copy link
Member Author

hbagdi commented May 6, 2021

Some thoughts/questions?

  • What do we test and what should take priority? There are numerous things that we need to include tests for:
    • Diffing logic: (mainly the diff package) This involves giving the diff engine two states and let decK traverse those states and output diff events. Verification involves ensure that the events generated are correct.
    • e2e: Given an state file, run decK and see what it outputs. This verifies if decK correct generates the right output on stdout. The verification trusts decK to do the right thing in this case if the text on stdout is right.
      • Something to add here would be to make API calls against Kong to ensure that the state that decK assumed that it successfully created actually matches the reality. This is meant to detect bugs inside the solver package and wiring of components inside decK.
      • This can be done against different versions of Kong.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants