这是一个单元测试吗？
开始伪代码...
CheckForDuplicateSubdomains(){
get all users in DB with matching subdomains
if greater than zero, fail test
}
PS：我正在使用C#的ASP.NET MVC
您对于单元测试的理解是正确的。单元测试的目的是逐一测试所有函数，使用不同的输入数据来确保它们按照您的预期工作（而不是在将它们插入应用程序后才发现问题，从而导致测试变得更加复杂）。
在编写函数之前编写单元测试是“测试驱动开发”方法论的一部分。您首先只编写函数的框架和所有单元测试。这样，起初所有的测试都会失败（因为函数还未被编程）。然后您编写函数，直到所有测试通过为止。
单元测试是在单元级别上进行的自动化测试。 在此级别上，它们指原子代码单元，例如无法进一步分解的函数或对象的特定部分。 一个计算平方的函数的单元测试可能看起来像：
assertEqual(4, square(2));
assertEqual(4, square(-2));
assertEqual(0, square(0));
现在，一旦您已经确定了正方形的接口，就可以立即编写此代码。对于更复杂的函数，您可以通过测试通过的数量来衡量函数完成的程度。
单元测试是指测试您代码的一小部分，通常是一个方法（确切地说是一个单元）。
在TDD中，开发人员可以在编写方法之前编写单元测试，因为他们已经知道代码单元应该执行什么操作。它不关心它如何执行工作......测试只是确保结果是正确的。
那段伪代码也可以用作单元测试（不确定它要测试什么，但我必须假设您正在测试一个不应返回重复子域的方法）。
理论上，单元测试（和测试驱动开发）应该通过确保每个代码单元都按预期执行来减轻以后的头痛。
是的，你的例子可以作为一个单元测试。创建测试的原因有几个。首先，它作为项目的实时文档。它建立了行为和预期结果，这应该有助于您实际实现代码（知道它需要做什么以及基本如何启动它，编写代码会更容易）。其次，如果您事后编写测试，您更有可能编写与您已经编写的代码兼容的测试，这对您没有帮助。定义代码单元需要执行的操作，编写测试，然后编写/修复代码，使其反映测试中的行为。这种策略将转化为随着应用程序发展而提高的理解和质量。
在 xUnit 框架系列中，有非常成熟的单元测试约定，最初源于 jUnit。在该框架中，断言是进行测试的主要方式。在测试套件中，目标是确保你所有的断言都是正确的，达到100%。
考虑你的例子。
CheckForDuplicateSubdomains(){
get all users in DB with matching subdomains
if greater than zero, fail test
}
这个测试通常会以“test”开头命名，这样框架的测试运行器就知道这个函数是一个测试而不是设置方法。重要的是要清楚地表明，我们正在测试代码的行为，而不是数据的状态。
testNoDuplicateSubdomains(){
}
在每个测试中，都有四个阶段：
SUT是“被测试系统”，通常是您生产代码中的一个类的方法。
testNoDuplicateSubdomains(){
// fixture setup
prepareDatabaseTestData()
// exercise SUT,
SUT = new ProductionObject()
result = SUT.getAllUsersWithMatchingSubDomains()
// result verification and
assertEmpty(result) // or whatever makes sense
// fixture teardown.
removeDatabaseTestData()
}
和许多软件开发技术一样，编写单元测试需要一定的经验。学习最佳实践的好资源是Gerard Meszaros的xUnit Test Patterns。