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

Adding CI from GitHubActions for tests #25

Open
Alex0vSky opened this issue Oct 21, 2023 · 5 comments
Open

Adding CI from GitHubActions for tests #25

Alex0vSky opened this issue Oct 21, 2023 · 5 comments
Labels
enhancement New feature or request

Comments

@Alex0vSky
Copy link
Collaborator

Alex0vSky commented Oct 21, 2023

Conversation from #23:

Can I do checks in CI from GitHubAction? I understand this a little.

Yes, it's a good idea, we require CI for writing and executing tests.

About writing tests, from the top of my head:

  1. EXPECT_MODULE_FUNC_CALL and ON_MODULE_FUNC_CALL
    for the WinApi function starting from zero arguments up to 12 from for example CreateWindowExA().
  2. Handling initialization errors
  3. Handling hook errors, set and unset
  4. GTest conflict workaround/bypass
  5. Others such as RESTORE_MODULE_FUNC and VERIFY_AND_CLEAR_MODULE_FUNC_EXPECTATIONS

It would be enough?

@Alex0vSky Alex0vSky added the enhancement New feature or request label Oct 21, 2023
@smalti
Copy link
Owner

smalti commented Oct 23, 2023

It would be enough?

Yes, I think it's a good set of tests, and we can also add:

  • Tests for Windows ApiSet DLL redirection, RoInitialize (used in gmock-win32-sample) or another function
  • Tests that use INVOKE_REAL_MODULE_FUNC and REAL_MODULE_FUNC

This was referenced Jan 3, 2024
@Alex0vSky
Copy link
Collaborator Author

Alex0vSky commented Feb 3, 2024

Here are the fist CI logs:
https://github.com/smalti/gmock-win32/actions/runs/7767518532/job/21184418906
See "Build and run all tests in loop" node.
Used: 2Mb cache for "gmock+gtest" and ~4 minutes of time.

  • Let's add the "Optimization" combination?
  • And I propose to get rid of the "Debug" combination; there is no influence of the "_DEBUG" macro in the library code.

As soon as we make a decision, I will delete the discussion #29.
And we’ll also add an elementary "badge" to the readme.

There are still many questions... Auto releases, SemVer, behavior on error/failure, smart "badge"...

@Alex0vSky
Copy link
Collaborator Author

Alex0vSky commented Feb 5, 2024

And I propose to get rid of the "Debug" combination; there is no influence of the "_DEBUG" macro in the library code.

Goodbye "_DEBUG", see you soon.

Let's add the "Optimization" combination?

Done in #38. Execution time: ~9 minutes.

And we’ll also add an elementary "badge" to the readme.

Done in #37. The path is configured correctly for this repo, and not for my fork.

@smalti
Copy link
Owner

smalti commented Feb 6, 2024

Done in #38. Execution time: ~9 minutes.

Thanks!

Goodbye "_DEBUG", see you soon.

+1

@Alex0vSky
Copy link
Collaborator Author

My discussion/question #29 is closed, since we have reached a common opinion and there is no negative reaction to the first results of CI over time.
Closed due to success.

One from last action to close this thread lead in new issue #39.
We can then decide what to do if an error/failure occurs in the tests.

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

No branches or pull requests

2 participants