How can you keep a password safe when it is needed for Integration tests?

In our organization we have an old legacy system that requires a plain-text password.

When making calls from our .Net webservices we need to supply our own username/password, so when writing integration tests we are hard-coding the credentials.

The tests开发者_高级运维 are executed using NUnit, and only executed on our local machines. What's the best way to secure our passwords without exposing them to other developers who checkout the source code?

You could use a properties file. Each developer has their own file on their machine, but the system always assumes that this properties file will exist with the variables.

When we use a tool like Subversion, we normally have a file titled something like "properties.txt.tmpl" which is the master definition of the properties file. Each developer would then be responsible for copying that to properties.txt, and making sure that any changes to the .txt.tmpl file were made to their local copy.

Then all we have to do is set Subversion to ignore the properties.txt file, and we don't get any conflicts.

How about as an organization you make an account on the machine specifically for testing with username dev and password password. If you're writing integration tests against this machine, I'm assuming it's not production, so no one would mind a dummy account...(I'm assuming). That's what we do at my company, every server, database, web service, etc in a development/test environment has a dev account.

Like Roly said, you should have a separate test database with a known set of data. Your integration tests can run against it with a "test" set of credentials.

Then, all you have to do is set up your tests to properly clean up after themselves (if they create records, delete them, reset status flags, etc). This has the distinct advantage of letting you schedule your integration tests to run as part of a larger system test, as well as making the tests less brittle.

In general, integration tests that run against a local database are going to be brittle, because you can't depend on the data being consistent from run to run. If you set up your data for a test case and run your integration tests against it, it's going to break the second you restore from a production backup. Another developer isn't guaranteed to have the same test data as you, so if someone else is working on your code and runs your tests, it might break. Or if you just choose some old data that's not likely to change to test against, there's no guarantee it won't at some point. Then, bam, failing test.

I've had good luck with having a dedicated test server that has the sole purpose of running integration tests. The important part is to ensure that the data is always consistent and that every test cleans up after itself properly, even in failure cases.