How to prevent/detect fetching data from another database on same server
To find objects in the database (views, procedures etc) that use 3 (or 4) part naming, you can use the scripts in this article to search the SQL Dependencies in the database.
SELECT OBJECT_SCHEMA_NAME(objects.object_id) 
                            AS referencing_schema_name,
       objects.name AS referencing_object_name,
      objects.type_desc referencing_object_type,
      CASE WHEN referenced_database_name = DB_NAME() 
                  AND referenced_server_name IS NULL 
            THEN 'Internal' ELSE 'External' END 
                        AS referenced_database_location,
COALESCE(sql_expression_dependencies.referenced_server_name,  
         '&lt;localserver&gt;') AS referenced_server_name,
       sql_expression_dependencies.referenced_database_name,
       sql_expression_dependencies.referenced_schema_name,
       sql_expression_dependencies.referenced_entity_name 
                                    AS referenced_object_name
FROM sys.sql_expression_dependencies
        JOIN sys.objects
            ON objects.object_id = 
                   sql_expression_dependencies.referencing_id
WHERE referenced_database_name IS NOT NULL
ORDER BY referencing_schema_name,referencing_object_name

There is also a script on that article for finding dynamic SQL in objects in the database. This doesn't mean they're using 3-part naming, but at least gives you a starting point for your searching.
As for the code in C#, that is going to be more difficult to find. You might be better placed to take a copy of your production DB and restore it to a non-production server that doesn't have the Test DB on it, then run your application against that database (which is now technically non-production). With the Test DB missing, you should get errors wherever you have references to the Test DB in application code.
You can then iteratively resolve each error and progress further with the application until you've got it working without errors. You could also setup up an Extended Events session filtered by user and database (Test DB) to record sqlserver.sql_statement_completed events. Periodically check this events session to see any queries executing against the Test DB by your production user to further identify problem queries and resolve.
Lastly, as a general best practice - take Test DB off your production server and put it somewhere else. This will guarantee that cross database queries to Test DB will fail (because it won't exist on production) and help prevent these kind of cross-contamination issues between environments. It also means you can treat your production environment as a true production, so the next time you have an external contractor come in to write reports/applications, they can develop in the test environment, and any issues with hard-coded DB or server names will become immediately apparent during deployment.