0
votes

I have a TFS 2017 instance running on windows server 2012 R2 with a test box running windows 10.

I am running into a very odd issue. Most of my automated CodedUI tests are running pretty well. However, I have noticed that code changes are not always picked up by TFS when it performs a new build, at least not in the testing code area.

The builds themselves work well, and new code always gets incorporated for those. However, when the latest build triggers a release containing CodedUI tests, those tests do not always grab the latest build.

I have noticed this primarily in my App.config file which contains connection strings that are not being updated. In one case I had three tests that ran apparently successfully, but then they ran again using the values from the old App.config file.

I also have found that changes to the [TestCategory()] attribute are not always picked up either. I use that category to specify which tests I want run in a particular release build. I use variations on the same word for my categories: CodedUI, CodedUIExtended, CodedUIStage. At first I thought the system was doing some sort of StartsWith and picking up the other names, but when I tell it to run CodedUI it is running both the CodedUI and CodedUIStage categories.

    [TestCategory("CodedUI"), TestMethod]
    public void UI_Login_AdminAuthenticate()
    {
       ...
    }

Because the CodedUIStage categories were recently changed and used to be CodedUI that has led me in the direction of suspecting some sort of caching being used in TFS.

Can anyone shed some light on why my category and app.config changes are not being picked up correctly? What is causing this, and could it be happening to the code itself as well when I attempt to deploy a fix/correction?

EDIT:

As suggested, I tried checking the clean option on my TFS build configuration, however it had no affect. The release, which is triggered immediately upon build does show it is using the newly finished build number. And looking at the artifacts, the test dll has the current date modified, so it looks like it was just created.

The test.dll.config seems to be the issue. In the artifacts it has a very old Date modified and is not the current version that is checked into TFS. Typically this would feel like a clean issue, however TFS always deletes and re-copies all destination files when doing a build or Release. I have verified that by watching the files being deleted and re-created on the file system during the process. C:\agent_work\r6\a\ [artifact_name]\bin

EDIT2:

With a little more exploration, the build artifacts are correct. It is when the Release copies those artifacts into the release process that the problem happens.

A week ago I renamed the folder in TFS containing my test project inside the solution. The old folder name is showing up in the artifacts the Release copies into itself. The new folder name is also showing up, which means I now have two dlls, and that is causing problems.

I am not sure where the Release is finding this copy of the old folder. I explicitly deleted it from the Release's copy of the build artifacts and re-ran the build and release and it showed back up.

1
How do you know that, "those tests do not always grab the latest build"? What build is the release definition running? Have you looked at the build outputs to validate that the files in the build are correct? How are you deploying the tests to the test agent machine? Are you using TFVC for version control? If so, is your build definition set to clean the repo prior to build? These are all things to investigate in order to narrow down your problem.Daniel Mann
I am not using the SVN option for version control, and I believe the only other option is TFVC. The configuration is set to always grab the latest build. I am using the normal TFS build agent to deploy the tests. No, the build does not do a clean first, I will try that. From watching the files that get pulled down during a build the folder always gets deleted so I do not know what a clean will accomplish, but it is worth trying. The tests "do not grab the latest build" because they are using valid code from older test dlls.Jereme Guenther
That was supposed to be GIT not SVN. I am using the native TFS option which has been around since conception.Jereme Guenther
"The tests "do not grab the latest build" because they are using valid code from older test dlls." How do you know that? You're making an assumption about the origin of the problem based on the symptom. It's easy to check. Look at the release that ran the tests. What build is it using? Look at the build it's using. What are the artifacts? Test the artifacts separately from the process. Are you still seeing the problem? Okay, then it's a problem with what's being built. Then you can investigate the build side of things.Daniel Mann
It's impossible to troubleshoot this without isolating the problem. You need to explain exactly how you've stepped through the process from "retrieving source during a build" through to "running the tests in a release definition" and explain what you've eliminated as a potential source and how you came to that conclusion.Daniel Mann

1 Answers

0
votes

Thanks to the suggestions from Daniel, I eventually figured out that after creating the artifacts, my build process was then publishing those to a separate place on the file system.

Unfortunately, the Copy and Publish Build Artifacts task does not have a clean feature like the basic Copy Files task does.

As such, whenever files are removed from the build they still exist in that location when the Release process goes to try and grab what it thinks the artifacts are. And so it ends up grabbing extra files.

Manually deleting the old files from that secondary artifact destination location solved the issue.