Forum Discussion

dhundley's avatar
dhundley
Regular Contributor
2 years ago

execution plan enabled difference between local and azure

i have an execution plan that doesn't always have every test item/test case enabled.    i came up with the following for loop that (when the plan is running on my local machine) is able to...
  • AlexKaras's avatar
    AlexKaras
    2 years ago

    Hi,

     

    I am not Azure guru and might be wrong here, but my understanding is that VS Test Steps component makes it possible to utilize unit tests runner to execute unit tests. And, as per Support, TestComplete Test Adapter is used to provide this runner with a list of tests (that will be executed using unit tests concept). So I think that both these components can be removed if you are going to use Command Prompt task.

    Not sure about e-Mail step - it might or might not work depending on how it is configured. For example, it may stop working if it is set to mail published test result (as the result is published by VS Test Step adapter, if I am not mistaken). But if e-Mail sends result that is prepared by TestComplete itself, than I see no reason why it should stop working.

     

dhundley's avatar
dhundley
Regular Contributor

so the last entry in that post was this:

if i'm understanding this correctly then i should replace the adapter step in my pipeline (shown below)

 

with a simple command prompt task in which i use the testexecute command line arguments to run things (see below). does the command prompt also eliminate the Visual Studio test steps? and if that's true then i suppose i wouldn't even need the Visual Studio test platform installer step. not shown in the image above is an emails step at the end that sends an email with any failed test cases. will that step still work with the command prompt step? 

 

AlexKaras's avatar
AlexKaras
Champion Level 3
2 years ago

Hi,

 

I am not Azure guru and might be wrong here, but my understanding is that VS Test Steps component makes it possible to utilize unit tests runner to execute unit tests. And, as per Support, TestComplete Test Adapter is used to provide this runner with a list of tests (that will be executed using unit tests concept). So I think that both these components can be removed if you are going to use Command Prompt task.

Not sure about e-Mail step - it might or might not work depending on how it is configured. For example, it may stop working if it is set to mail published test result (as the result is published by VS Test Step adapter, if I am not mistaken). But if e-Mail sends result that is prepared by TestComplete itself, than I see no reason why it should stop working.

 

  • dhundley's avatar
    dhundley
    Regular Contributor
    2 years ago

    AlexKaras this looks very promising. i tried running the new pipeline containing only the Command Line Script step (no testcomplete or visual studio test steps) with the TC arguments set up so that it pointed to the existing azure repo for my application. it completed successfully but i did have to manually click on a confirmation that popped up

    would the silentmode argument be a way to avoid that?  there were also no pictures automatically posted in the log (as there are using the other method) but i can get around that by specifically using the Log.Picture method everywhere in my project that I want to see what's on the screen at any given point. I will do some additional tests and let you know the final outcome. thanks for the suggestion!!!

     

    • AlexKaras's avatar
      AlexKaras
      Champion Level 3
      2 years ago

      Hi,

       

      > would the silentmode argument be a way to avoid that?

      Yes, correct. SilentMode argument just accepts all defaults for dialogs that are going to be displayed and prevents them from been displayed.

       

      > there were also no pictures automatically posted in the log

      Not sure what automatically posted pictures you are talking about but yes, you can either post a picture using Log.Picture() or provide a picture as a parameter for the Log.Warning() or Log.Message() methods.