VS2019: Test explorer is not discovering tests

[anddrzejb]

Hi @GoEddie, great work so far on the test adapter.
I have this problem that my tests suddenly are not discovered by test explorer.
I even created a new project from scratch just to see if I messed something up in my original project, but even in a very simple example (I used this tutorial mentioned in the issues before), I cannot see the tests.

Any ideas what should I do?

My setup:
WIN10 Pro
VS2019 16.4.3
MSSQL Express 2017
tSQLt-TestAdapter 0.99
repro

[GoEddie]

Have you selected the runsettings file in the test window config?

[anddrzejb]

Yes I did

[GoEddie]

I’ll try and take a look early next week, let me know if you find out the issue before

[GoEddie]

I’ll try and take a look early next week, let me know if you find out the issue before

[anddrzejb]

Sure I will. Although I am not sure what else I can do. I did see a question raised about logging, and I was thinking maybe I can have a look there, maybe the adaptor will tell me what is up...but I have to find time to do it and I am not very proficient when it comes to debugging extensions... Anyway, I will post if I find something.

[DanielMGC]

Has anyone found something about this yet, because I'm having the same issue. Followed the same tutorial and after doing all the steps, no tests are being discovered.
Checked runsettings and even restarted from scratch multiple times, to no avail.

My setup:
WIN 10 Pro
Visual Studio Professional 2019 Version 16.4.5
SQL Server 2017 (14.0.2027.2)
tSQLt 1.0.5873.27393
tSQLt Adapter 0.99

I wonder if it can be related to VS version?

[DavidJohnParsons]

I am having the same issue:

Windows 10 Pro
Visual Studio Community 2019
SQL Server 2014 (12.0.4237.0)
tSQLt version 1.0.5873.27393
tSQLt Adapter 0.99

I have a .runsettings file that has the correct connection string

The test procedures and scripts for these procedures are all named 'Test[*]'

The tests run if executed directly via Management Studio

However, the tests do not appear in Test Explorer. If I select 'Run All' it triggers a build of all the projects in the solution but nothing else.

[anddrzejb]

I finally found some time to investigate. First a disclaimer - by no means I understand how to create VS extensions. While investigating I created 1 example extension and that was it.

So my process was to first try to analyse what is happening on a working version (VS2017). Mostly I think I figured it out, I was able to debug it (to some extent).
Then I started debugging on VS2019. To my surprise, when running in experimental mode, everything was working fine. To explain what experimental mode is -> when debugging extension, a new instance of VS is run in experimental mode where any project, in my case the database with tests, can be started. Because of my lack of knowledge on how to log in an extension, I decided to do a very basic logging - I added file creation with a time stamp in the class that should receive the test explorer (area where the adapter is actually starting its operations, class tSQLtTestContainerDiscoverer). When running in experimental mode, the file was created.
After that, I used the extension package built by my tests to install it.
I run the same database project that was working while debugging, and unfortunately, the adapter did not pick up the tests. It seems the adapter was not initialised, my basic file logging didn't create my logging file. I was running VS2019 with elevated permissions. Here is where my analysis hit the wall and I do not know what to do further. So, @GoEddie, does that make any sens? Do you have any idea what could be the source of this problem? Or anyone else, with some experience on extension building?

[tbjerknes]

Hi

I tried your repro. I made it work in my VS 2019 after a bit of tweaking. I see you test against a database called Transport. Is that intentional? This is your settings file:

Anyway, I test against (localdb)\ProjectsV13 and not (localdb)\MSSQLLocalDB. See picture below:

I'm just starting out with tSQLt, so I'm no expert, but I think the connection in the runsettings file, should be the same as what you have in your project properties, debug:

[anddrzejb]

You are right, the Transport was left there by accident. I forgot to fix the connection string, but during my tests, I changed it to the database that I published the ssdt project to. I did not try on ProjectsV13, but tried on localdb and on a regular SQL Server Instance... Can you tell us here what exactly is your setup, including other extensions you have installed?

[tbjerknes]

I'm on Visual Studio 2019 professional, version 16.5.4. Windows 10. I couldn't make it work on MSSQL LocalDb at all. It doesn't discover any tests, just like in your case. It only works when I switch to (localdb)\ProjectsV13. Try and see if it makes a difference for you to. My extensions can be viewed below. Another thing: Do your tests work properly without the adapter? ie with a post deployment script where you run EXEC tSQLt.RunAll ?

[anddrzejb]

Yes, this is how I am currently developing. Actually, I just run them from SSDT, but occasionally I also run them from SSMS (without any issues). You said you tried on ProjectV13, did you also try on standalone instance (for example SqlExpress or Dev version)? I am in the middle of something, but I will have a look at your findings as soon as I can. If we can reproduce this on multiple machines, that would be probably a step forward...

[radioman09]

I am having the same issue as well. Visual studio 2019. My connection string matches whats in debug as well. Publish works correctly on target db. Tests do not show.

[chunges]

I opened the TestDBProject.UnitTest solution in VS SSDT 2017, the test explorer showed the test.

Then I closed and opened again same solution in VS 2019, and now the Test explorer showed the test.
Closed the VS SSDT 2017. And VS 2019 Test explorer still showing the test and can ran test as expected.

[Dean-McMillan]

Same issue for me unfortunately.

WIN 10 Enterprise
Visual Studio Enterprise 2019 Version 16.9.3
SQL Server 2019 (15.0.2070.41)
tSQLt_V1.0.7682.21917

Is there a fix for this? Or should I give up on VS2019 and have a go with an earlier VS version?