2019-05-29 18:08 阅读 26

如何模拟* ec2.DescribeVolumesOutput的值

I am currently trying to get used to TDD and on a current project I am working on I am trying to leverage AWS's Go SDK. Which is all fine and dandy and I have used it before but I am currently trying to mock the value that *ec2.DescribeVolumesOutput sends.

Diving into the code I see this as what returns for *ec2.DescribeVolumesOutput:

type DescribeVolumesOutput struct {
    _ struct{} `type:"structure"`

    // The NextToken value to include in a future DescribeVolumes request. When
    // the results of a DescribeVolumes request exceed MaxResults, this value can
    // be used to retrieve the next page of results. This value is null when there
    // are no more results to return.
    NextToken *string `locationName:"nextToken" type:"string"`

    // Information about the volumes.
    Volumes []*Volume `locationName:"volumeSet" locationNameList:"item" type:"list"`

Okay.. That's cool, but what I want to mock the output of must live inside of Volumes []*VolumelocationName:"volumeSet" locationNameList:"item" type:"list"` so let's go a little deeper and see what that is...

type Volume struct {
    _ struct{} `type:"structure"`

    // Information about the volume attachments.
    Attachments []*VolumeAttachment `locationName:"attachmentSet" locationNameList:"item" type:"list"`

    // The Availability Zone for the volume.
    AvailabilityZone *string `locationName:"availabilityZone" type:"string"`

    // The time stamp when volume creation was initiated.
    CreateTime *time.Time `locationName:"createTime" type:"timestamp"`

    // Indicates whether the volume will be encrypted.
    Encrypted *bool `locationName:"encrypted" type:"boolean"`

    // The number of I/O operations per second (IOPS) that the volume supports.
    // For Provisioned IOPS SSD volumes, this represents the number of IOPS that
    // are provisioned for the volume. For General Purpose SSD volumes, this represents
    // the baseline performance of the volume and the rate at which the volume accumulates
    // I/O credits for bursting. For more information, see Amazon EBS Volume Types
    // (
    // in the Amazon Elastic Compute Cloud User Guide.
    // Constraints: Range is 100-16,000 IOPS for gp2 volumes and 100 to 64,000IOPS
    // for io1 volumes, in most Regions. The maximum IOPS for io1 of 64,000 is guaranteed
    // only on Nitro-based instances (
    // Other instance families guarantee performance up to 32,000 IOPS.
    // Condition: This parameter is required for requests to create io1 volumes;
    // it is not used in requests to create gp2, st1, sc1, or standard volumes.
    Iops *int64 `locationName:"iops" type:"integer"`

    // The full ARN of the AWS Key Management Service (AWS KMS) customer master
    // key (CMK) that was used to protect the volume encryption key for the volume.
    KmsKeyId *string `locationName:"kmsKeyId" type:"string"`

    // The size of the volume, in GiBs.
    Size *int64 `locationName:"size" type:"integer"`

    // The snapshot from which the volume was created, if applicable.
    SnapshotId *string `locationName:"snapshotId" type:"string"`

    // The volume state.
    State *string `locationName:"status" type:"string" enum:"VolumeState"`

    // Any tags assigned to the volume.
    Tags []*Tag `locationName:"tagSet" locationNameList:"item" type:"list"`

    // The ID of the volume.
    VolumeId *string `locationName:"volumeId" type:"string"`

    // The volume type. This can be gp2 for General Purpose SSD, io1 for Provisioned
    // IOPS SSD, st1 for Throughput Optimized HDD, sc1 for Cold HDD, or standard
    // for Magnetic volumes.
    VolumeType *string `locationName:"volumeType" type:"string" enum:"VolumeType"`

Nice! this looks like some data that I want to mock the values of!

But over the last couple of days I have had no luck in actually mocking these values. Are they so nested that this type of mocking is not worth the effort? Even trying to use the does not seem to help me wrap my head around how to properly package some mock value returns to test. Am I coming at TDD all wrong? am I missing something super obvious? I do not really have example code to show since I now no longer understand what I am trying to do.

Does anyone possibly have an example of how they have mocked this?

  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享

1条回答 默认 最新

  • 已采纳
    douguanyan9928 douguanyan9928 2019-05-29 21:37

    There is no way to mock the type, you are able to mock only implementation of the interface. In your case I assume that you are trying to call DescribeVolumes and in the response get value constructed by you.
    To do that you need to create a mock like

    type MockEC2API struct {
        ec2iface.EC2API // embedding of the interface is needed to skip implementation of all methods
        DescribeVolumesMethod func(*ec2.DescribeVolumesInput) (*ec2.DescribeVolumesOutput, error)
    func (m *MockEC2API) DescribeVolumes(in *ec2.DescribeVolumesInput) (*ec2.DescribeVolumesOutput, error) {
        if m.DescribeVolumesMethod != nil {
            return m.DescribeVolumesMethod(in)
        return nil, nil // return any value you think is good for you

    In the test create instance of MockEC2API instead of the real ec2.EC2 and provide it with function that will be called and return your's prepared ec2.DescribeVolumesOutput result

    ec2 := &MockEC2API{
        DescribeVolumesMethod: func(*ec2.DescribeVolumesInput) (*ec2.DescribeVolumesOutput, error) {
            return &ec2.DescribeVolumesOutput{...your initialization...}, nil
    output, err := ec2.DescribeVolumes(in) // this output will be your prepared initialization
    点赞 评论 复制链接分享