Suppose I have several services represented by classes ServiceA, ServiceB, ServiceC etc.
These services have configuration and other data in SQL, in for example a ServiceConfiguration table.
Are there any best practices for linking ServiceA to it’s corresponding configuration and data in SQL other than hard-coding the Id in the class?
And any thoughts on testability?
I can verify that, for example, ServiceA returns true for IsValidServiceForId(1) — but if it’s configuration id were to change in SQL for some unknown reason, the test would still pass.
I could add to the test an assertion verifying that I can get a configuration record for a service matching name “Service A”, but that would then introduce an extra dependency into my test class – I would then also be testing the ServiceConfigurationRepository (for example).
Edit
I thought this would be a platform agnostic question, but for info I’m using C#, .Net 3.5, NUnit for testing, NHibernate with SQL Server.
If these services are directly hitting the DB for their config, and you need to test them, abstract away the configuration.
When testing, you give your services a mocked configuration.
When actually running the app, you give your services the real configuration, fetched from the DB.
Sorry for being so vague, but without any code, it’s hard not to be.