microsoft / azure-pipelines-task-lib

Libraries for writing VSTS and TFS build tasks
https://aka.ms/tfbuild
MIT License
402 stars 266 forks source link

Unit testing starts to fail when I upgrade to 2.0.5. #264

Closed TsuyoshiUshio closed 5 years ago

TsuyoshiUshio commented 7 years ago

I upgrade vsts-task-lib to 2.0.5. Then My unit testing starts to fail. It works for the old version.

In this case, I mock "bash" execution. I mock like this.

/// <reference path="../typings/globals/node/index.d.ts" />

import ma = require('vsts-task-lib/mock-answer');
import tmrm = require('vsts-task-lib/mock-run');
import path = require('path');

let taskPath = path.join(__dirname, '..', 'downloader.js');
let tr: tmrm.TaskMockRunner = new tmrm.TaskMockRunner(taskPath);

tr.setInput('kubectlBinary', process.cwd());
tr.setInput('k8sService', 'k8sendpoint');
tr.setInput('hasIstio', 'true');
tr.setInput('IstioVersion', "0.1.6");
tr.setInput('hasHelm', 'true');
tr.setInput('helmVersion', '2.4.2')

process.env['SYSTEM_DEFAULTWORKINGDIRECTORY'] = '/opt/vsts/work/r1/a'
process.env['ENDPOINT_AUTH_PARAMETER_K8SENDPOINT_KUBECONFIG'] = `

---
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: "XXXXXXXXXXXXXXXX"
    server: https://xxxxxxxxmgmt.japanwest.cloudapp.azure.com
  name: "xxxxxxxxmgmt"
contexts:
- context:
    cluster: "xxxxxxxxmgmt"
    user: "xxxxxxxxmgmt-admin"
  name: "xxxxxxxxmgmt"
current-context: "xxxxxxxxmgmt"
kind: Config
users:
- name: "xxxxxxxxmgmt-admin"
  user:
    client-certificate-data: "XXXXXXXXXX"
    client-key-data: "XXXXXXXXXXXXXXXXXX"

`;

let a: ma.TaskLibAnswers = <ma.TaskLibAnswers> {
    "which": {
        "bash":  "/bin/bash",
    },
    "checkPath": {
        "./Tests/my-nginx.yml": true,
        "/opt/vsts/work/r1/a/.vstsbin/kubectl.vSomeVersion": true,
        "./kubeconfig": true,
        "/bin/bash": true,
    },
    "cwd": {
        "cwd": process.cwd(),
    },
    "osType": {
        "osType": "Linux",
    },
    "exec": {
        "curl -L https://storage.googleapis.com/kubernetes-release/release/stable.txt": {
          "code": 0,
          "stdout": "vSomeVersion"  
       },
        "curl -L -o /opt/vsts/work/r1/a/.vstsbin/kubectl.vSomeVersion https://storage.googleapis.com/kubernetes-release/release/vSomeVersion/bin/linux/amd64/kubectl": {
          "code": 0,
          "stdout": ""  
       },
        "chmod 777 /opt/vsts/work/r1/a/.vstsbin/kubectl.vSomeVersion": {
          "code": 0,
          "stdout": ""  
       },
        "cp /opt/vsts/work/r1/a/.vstsbin/kubectl.vSomeVersion /opt/vsts/work/r1/a/.vstsbin/kubectl": {
          "code": 0,
          "stdiout": ""
       },
       "mkdir -p /opt/vsts/work/r1/a/.vstsbin": {
          "code": 0,
          "stdiout": ""
        },
        "/bin/bash .istioctldownloader.sh": {
            "code": 0,
            "stdiout": ""
        },
        "/bin/bash .helmdownloader.sh": {
            "code": 0,
            "stdiout": ""
        }
    }
}

However, it fails like this. It seems we can mock the which method for the task. however, we have additional which that is escapes from the mocking.

##vso[task.debug]looking up mock answers for "which", key '"bash"'
##vso[task.debug]found mock response
##vso[task.debug]which '/bin/bash'
##vso[task.debug]not found

I suspect, this change https://github.com/Microsoft/vsts-task-lib/commit/4dd8ef3a52cd3e25fab3fbb8d9cb20728fd191ba

add following line on node/toolrunner.ts. This line might not be mocked by existing mock framework.

 this.toolPath = im._which(toolPath, true);
TsuyoshiUshio commented 7 years ago

It works properly until 2.0.3-preview.

stephenmichaelf commented 6 years ago

I will take a look, thanks!

damccorm commented 5 years ago

Just took a look at this and could no longer reproduce (using v2.6.0). Is this still an issue? Which mocking seems to be working for me.

damccorm commented 5 years ago

I'm going to close, please reopen if its still an issue.