add go-native e2e test cases for backend

[nehagup]

Is your feature request related to a problem? Please describe. Currently, integration tests are written using Cypress. Quick benefits for go e2e tests.

-> Reports on Backend(Go) Test Code Coverage. -> Backend Contributors can write go-native test cases independently without needing to understand Frontend/Cypress.
-> Opinionated - Backend Tests are less brittle than frontend tests in the long run.

Describe the solution you'd like I can make a PR which adds go-native e2e tests generated using Keploy which will run as part of the GitHub actions pipeline. It will also take care of the Postgres dependency mocks. With that, we'll also have a test coverage check as part of the GitHub-actions pipeline for the PRs and releases.

[knadh]

Thanks @nehagup. Would it be possible see how these tests look, if it's not too much effort? Just trying to understand how it works.

That said, Cypress frontend tests are still necessary because listmonk is primarily a web app with complex (and often brittle with DOM/JS lib weirdness) state management on the UI. It's only mode of operation is via the web app UI.

[nehagup]

Sure @knadh I'll make a PR for this in the upcoming week.

[nehagup]

@knadh how do you currently mock the SMTP server during testing? Do you run the mock SMTP server or you use some test-credentials?

[knadh]

I run a local instance of https://github.com/mailhog/MailHog. It's excellent.

[re-Tick]

Hi @knadh, I've a created a PR which show's how Keploy could generate tests for listmonk. I integrated keploy into the codebase (this requires passing context to every dependencies, so made relevant changes) and then used the listmonk UI to record bunch of API tests, as yamls in the tests folder. The current code coverage is 49.2% from these tests - which can be added by either writing go tests manually or generating more via keploy.

The SQL calls are also recorded as editable yaml stub files corresponding to the API calls, and are saved in the mocks folder. This PR took time because we were in the midst of revamping our SQL driver - to create readable and editable stub. files, and wanted to show you that version.

I've also added a github action - which would require your approval to run. It runs the test but we can also integrate tools like coveralls to get line-by-line coverage or coverage policy check for PRs

Looking forward to your thoughts

[knadh]

Hi @re-Tick. How do I run the tests locally?

[re-Tick]

I have edited the test job in Makefile. So, the steps for running this locally are:

1. First start the keploy server. Follow this Quick Installation to install and run keploy binary.
2. Then, just run "make test" in other terminal.

[knadh]

Hi @re-Tick. Finally got a chance to run this locally.

make test seems to have run fine, but the local instance of keploy (latest bin) shows this when trying to view the results on localhost:6789

Error! server selection error: server selection timeout, current topology: { Type: Unknown, Servers: [{ Addr: localhost:27017, Type: Unknown, Last error: connection() error occured during connection handshake: dial tcp [::1]:27017: connect: connection refused }, ] }

[re-Tick]

Yes, because we have deprecated the UI. You could use the keploy binary console output for viewing the test summary. There’s also a yaml file generated in the same folder where you run the keploy binary for more details.

Keploy initially only supported saving test results to mongodb, and later we added file generation. The UI has not been updated to support that yet. The error is related to the UI controllers not being able to connect to mongodb. We are working on cleaning up this experience.

[knadh]

Yep, it worked. Could you also explain how the stub files (YAML) are generated and how they're to be kept up-to-date when queries and responses change?

[re-Tick]

Record new tests

1. Install and run keploy. eg - https://github.com/keploy/keploy#macos
2. Start the application in record mode:

   export KEPLOY_MODE=record
   # start the application
   make run

3. Perform API calls

This would capture the req/resp of the API calls, and the DB calls in YAML format.

Update tests/stubs YAML

Either edit the YAML directly or just create new tests.

@knadh would love to know what you think 😊