refactor (crc/machine) : Provide a dummy implementation for virtualMachine object for writing unit tests (#4407)

[rohanKanojia]

Description

Fixes: Issue #4407

Relates to: Issue #4407, PR #4400

Type of change

• Bug fix (non-breaking change which fixes an issue)
• Feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change
• Chore (non-breaking change which doesn't affect codebase;
  test, version modification, documentation, etc.)

Checklist

• I have read the contributing guidelines
• My code follows the style guidelines of this project
• I Keep It Small and Simple: The smaller the PR is, the easier it is to review and have it merged
• I use conventional commits in my commit messages
• I have performed a self-review of my code
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• I tested my code on specified platforms
  • Linux
  • Windows
  • MacOS

Solution/Idea

• Add a VirtualMachine interface and make the CRC machine package client use the VirtualMachine interface instead of a concrete implementation. This way we can inject a dummy test FakeVirtualMachine implementation into client tests that can ease writing tests for this package.
  • Add some additional methods in VirtualMachine interface so that we can replace direct usage of struct fields with interface methods
    • Bundle()
    • Driver()
    • API()
    • GetHost()
• Add a new field VirtualMachine in the client so we can avoid creating it if it's already created.
• Introduce a new constructor method newClientWithVirtualMachine in machine client that would have an additional VirtualMachine argument, this would be kept package private so that it's used only by tests in the same package.
• Add FakeVirtualMachine sturct in fakemachine for adding dummy implementation for VirtualMachine interface. Currently, I've only completed methods used by stop_test.go, I'll add more in small increments as I get more familiar with the project.

Proposed changes

• Add new VirtualMachine interface and make client member functions use it instead of virtualMachine struct.
• Add new constructor in machine client to be able to override VirtualMachine implementation from tests
• These files have been modified to use VirtualMachine interface instead of virtualMachine struct (these changes are only related to changing use of virtualMachine struct to VirtualMachine interface:
  • pkg/crc/machine/ip.go
  • pkg/crc/machine/poweroff.go
  • pkg/crc/machine/start.go
  • pkg/crc/machine/status.go
  • pkg/crc/machine/stop.go

Testing

It's a small refactor. I've only run E2E tests locally to verify if these changes don't introduce any kind of regression.

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign cfergeau for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[openshift-ci]

Hi @rohanKanojia. Thanks for your PR.

I'm waiting for a crc-org member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[cfergeau]

In my opinion, the fact that crictl stop is the last command we run in the VM should be an implementation detail, it can change at any time if we refactor this code, if we add new things to the bundle which needs to be stopped, ...

[rohanKanojia]

Thanks for review, I'll remove this assertion.