Regardless if the production server is on a hosting provider or not, I would not put the testing framework and the test code on the production server. The TST database and even your test procedures should not be on the WinHost servers. The usual approach to
this is to have a development or test environment and automate your tests there. For example you could have a build automation that has the test automation as one step (usually one of the last steps). The build automation could run on the development machine(s).
For larger projects it is common to have one or more test machines where the build process (including test automation) would also be run.
I need to make here a distinction between test automation and data validation. The fact that you consider placing test code on a production server makes me believe that you may talk about data validation rather than test automation. Here is what I mean by
- Test automation: the behavior of your code is tested against some known data and a known scenario. You can do that on a test / development environment. There is no need to use a production server for something like this.
- Data validation: you may have rules that cannot be expressed in things like foreign keys or other type of constraints. You can write code (functions or stored procedures) that finds cases where those rules are violated. You can run this data validation
code based on a schedule. If a violation is found you may not necessarily know what kind of scenario produced those violations but you could at least find them early. Data validation is useful on both tests environments and production environments.
T.S.T. is for test automation. Data validation is a little bit out of the scope of T.S.T.