I think it is useful, at this point, to start to talk about a high level, development workflow for writing T-SQL. If we start with writing a new stored procedure, for example, the steps from sitting down starting to write the code all the way to deploying to production are something like:

1. Understand the requirements
2. Write the code against a private developer instance
3. Test the code
4. Deploy to another environment
5. Have the new code tested and approved
6. Deploy to production

If you have a full ci/cd pipeline with source control, then there will be some additional steps, but we will assume you are learning to write tSQLt tests so that you can start using ci/cd :)

The key point here is that you run your code on a private developer instance, if you share a database with other developers, using tSQLt will cause problems when multiple people use it and the same tables, at the same time.

So, where should you install tSQLt? The answer is a private developer database. I would go further and say that the database needs no data in at all, but we can leave this point for next week when we will go into this in detail.