I know it is confusing! I spent a week to get this working just trying a host of different ways until It finally worked. In my opinion there are no good tutorials on how to integrate it in VisualStudio. At least I have not found one, you have to piece it together from different sources. Anyway, this is my understanding of how it works from a Visual Studio perspective. I will explain my take on it below, but note that this is not the only way to do it. It may not even be the best way, but it has been working great for me since I started with it. The way it works in Visual Studio is conceptually a bit different than if you install tSQLt on your test server, or in the production database (only lunatics do the latter). Here goes:
You have the database you want to test in one project. This is not your real database with data and everything, but an import of all the objects from your real database. You add this to source control, you do your change management here (at least I do). And it works as a proxy of your real database you can test against. In your case that is SQLClientDBSchema.
Then you have your Unit testing project. You install tSQLt in this project. This is the only place I have tSQLt installed. You add master, and a reference to the main project. I will explain the steps again below, but conceptually the link between the projects are this: When you hit F5, It creates a copy of the main database in your test project. It also creates all the tSQLt objects in your test project. You create all your tests in your test project (you see a pattern here? :) ) . When run hit F5, it says that it deploys the database, which may sound confusing, but that is what is happening: It deploys it to your localdb:
This database contains everything! It contains the main db, tSQLt, and your tests. Everything you do from a testing perspective is against this database. This is important to understand, so when you mock a table, you don't mock a remote table (like in the article you referred to). You mock the table in your test project.
Lets say I have a table Customers in my database. I want to test against it. This table will end up in my localdb server through the deploy process explained above. I mock this table which is now in the debug database in my test project. No need to refer to some other database, or some other server. I write the tests against this mocked table. I know this is a valid test, because this table is a copy of the table in the main project, which again is a copy of the real world database. I am therefore testing the functionality of the real table in a roundabout way, but in a safe environment where I cannot ruin anything real! The database you see in the picture above is a throwaway database. You can right click and delete it. Run F5 and it comes back again with all the objects
When you write $(SqlClientSchema), you are using a variable to refer to objects in another project. Like this
Don't do that, at least that is not how I do it. I mentioned earlier that you have to add tSQLt and the main project as 'Same database'.
See now they end up in your test project, and you can refer to them directly. Does right click properties look like this in your project:
In startup projects, does it look like this? This is important!
My suggestion is that you delete your test project and start over (or create a second test project). Import tSQL as dacpac. I found this to be much easier than everything else