Activate Unit Test in Development and Test Phase and not Production phase

Question

Goal:
Unit testing method TestMethod1 can only be used in development and test phase. If it being used in production phase, everything will be canceled or similar.

Problem:
When I tried removing the string value "Development" from useEnvironment() method, the code is still working.

Is it possible to activate the unit testing in development and test phase and not in production phase?

Info:
*Source code is taken from https://www.meziantou.net/testing-an-asp-net-core-application-using-testserver.htm
*Please take account that you might have about 500 unit test.
*Using asp.net core mvc v3

Thank you!

-------------------

using Microsoft.AspNetCore.Hosting;  
using Microsoft.AspNetCore.TestHost;  
using System;  
using System.Collections.Generic;  
using System.Text;  
using Xunit;  
using System.Net.Http;  
using System.Threading.Tasks;  
using Testtest;  
  
namespace XUnitTestProject1.Test  
{  
    /// <summary>  
    /// https://www.meziantou.net/testing-an-asp-net-core-application-using-testserver.htm  
    /// </summary>  
    public class Tests  
    {  
        [Fact]  
        public async Task TestMethod1()  
        {  
            var webHostBuilder =  
                  new WebHostBuilder()  
                        .UseEnvironment("Development") // You can set the environment you want (development, staging, production)  
                        .UseStartup<Startup>(); // Startup class of your web app project  
  
            using (var server = new TestServer(webHostBuilder))  
            using (var client = server.CreateClient())  
            {  
                string result = await client.GetStringAsync("/api/values");  
                Assert.Equal("[\"value1\",\"value2\"]", result);  
            }  
        }  
    }  
}  

----

using Microsoft.AspNetCore.Mvc;  
using System;  
using System.Collections.Generic;  
using System.Linq;  
using System.Threading.Tasks;  
  
namespace Testtest.Controllers  
{  
    /// <summary>  
    /// ValuesController  
    /// </summary>  
    [ApiController]  
    [Route("api/[controller]")]  
    public class ValuesController : Controller  
    {  
        [HttpGet]  
        public IEnumerable<string> Get()  
        {  
            return new string[] { "value1", "value2" };  
        }  
    }  
}  

---

Answer 1

I'm unsure what you're trying to accomplish here but what would unit tests have to do with the environment they are run in? You normally wouldn't deploy your unit tests to a server so why is this an issue? Unit tests should be built and run as part of your app build and deployment scripts. For "production" builds/deploys you would simply skip running the test. Most people run the unit tests as part of their build so after the solution builds you have an explicit step to run the unit tests. If they pass then the build is valid otherwise it fails. This prevents you from deploying code that fails the tests.

Deployment tests might include integration tests. These tests would be run as part of your deployment script for similar reasons. However all the configuration would be handled as part of your deployment script, generally using environment variables. For production you wouldn't run the integration tests, if you choose to go that route. In any case the tests run the same, just different environment variables.

There is no reason, nor would I ever recommend, that you put any "environment-specific" logic into your tests. It doesn't make sense to me.

Answer 2

Thank you helping me to understand better of the situation!

1.
"You normally wouldn't deploy your unit tests to a server so why is this an issue?"

I'm not working with devops about releasing the software in production phase.
I didn't know that you normally wouldn't deploy unit test to production phase.

2.1.
"For "production" builds/deploys you would simply skip running the test".

If I understand correctly, When you use azure devops and you are ready to deploy the software in production phase, are you enable to select specific project from solution about which of the project should be release to production phase?

2.2.
"For "production" builds/deploys you would simply skip running the test".

You are enable to do it in azure devop's Saas, Paas and IaaS?

+

Are you enable to select specific project from solution about which of the project should be release to production phase in relation to Saas, Paas and IaaS?

Thank you!

Answer 3

2.1 Depends on your deployment tool but they all work similarly. Normally the build process packages everything up for deployment (packages to be pushed to a package management tool, apps and their data to be deployed to worker servers, published web app archives to be pushed to web servers, etc). The deployment tool then normally has a list of tasks to perform. The tasks indicate what to do, on what target machine, etc.

Example: Solution has a web UI front end and an API back end. These are likely deployed to different servers. The build would build and run the unit tests for both apps and then "publish" the apps to an archive file that can be later msdeploy/webdeploy to a target server. The deployment tool would then have tasks to deploy the web UI front end to the environment's front end web server and the API back end to the environment's back end web server. Whether you're using an actual deployment tool like Azure DevOps or a simple Powershell script doesn't matter.

NOTE: Some companies build and deploy as a single step into each environment. So if you have 3 environments you build/deploy 3 times. I don't agree with this approach as it is wasteful hence the build is environment-agnostic and runs once. The deployment tool is responsible for getting things into each environment correctly.

2.2 Doesn't matter what deployment tool you use. Powershell, Chef, Octopus, Azure DevOps - they all provide similar features. The purpose of a deployment tool is to configure a target machine and get the files onto it. This is the "deployment tasks" you need to do. For non-prod environments you could deploy integration tests if you wanted but in prod you'd skip that step. The deployment tool needs to know which environment it is going to so it can use that environment variable to determine what steps to skip. Again, each deployment tool works differently but they all provide this functionality.

2.3 Yes, again a deployment is just a series of tasks to perform. What those tasks are depends on your app and environment. In the case of a web app you likely have tasks to set up or change the app pool to run against, set up or change the web site configuration and then deploy the updated site to the web server. Each of these are tasks in the deployment tool you're using. If you need to run integration tests in non-prod then normally you'd deploy the app to the environment and then as a final task run the integration tests. You'd use whatever environment variable is used by your tool to determine whether it is a production release or not. In the case of Azure DevOps it supports stages with tasks in each stage. Many people use the stages as environments so each environment contains the custom tasks for it. In our case we'd have our Dev/QA stages include a task to run integration tests but our Prod stage would leave this task out. If you're doing this with something else like Powershell you'd need to use a PS variable to control.