Почему бы не поражать базу данных в модульных тестах?

There are two main reasons for unit tests not hiting the database:

• You want your tests to go as fast as possible
• You want to test your code as a single unit, not how it integrates with other code/ database.

In your case you need to test the stored procedures. Then you need to write a test that runs those stored procedures. Either you can run them via your code (Integration test) or you can run them directly from the test (sort of a unit test). In both cases you can use Nunit.

YMHO There is a bit of semantic issue and a bit of a technical issue here.

A unit test is supposed to test a small part of code, in isolation, to check it without other code. A failed Unit Test should imply that only a small part of code will have to be inspected corrected (tipically, the code implementing the functionality and the unit test itself).

Other scopes of testing exist to check functionality of the system as a whole (system test), or functional tests to validate complete features, or integration tests to check interactions, regression testing to check for the absence of already corrected test etc.

A testing strategy has to be devised for each project, but in general having different categories helps a lot. So unit tests should be restricted to testing the smallest possible units of code, and use other testing procedure to test functionality, integration etc.

The semantic part is whether is correct to use a unit test library to perform some functional test, I guess it is no biggy if you keep your suites separated the strict unit tests and the functional tests (even if they share the testing tool)

Дело в том, что если ваши модульные тесты попадают в базу данных, вы не тестируете только одну единицу кода, а вместо этого выполняете несколько - также и DAL, хранящийся процедуры и т. д. Вот почему сторонники TDD советуют не попадать в базу данных в юнит-тестах.

Это также то, почему вы не должны иметь большого веса в чистых, концептуализированных TDD, теоретических святых U nit T ests. Хотя модульное тестирование само по себе не так уж и плохо, и на самом деле очень важно для обеспечения правильной сборки каждого компонента программистами, гораздо важнее системное тестирование. В целом, может быть труднее найти точный метод, который привел к сбою системных тестов, они более реалистичны и фактически тестируют систему .
So-called "Component Testing" - which is more like system testing, but for only one small part of the system, end-to-end - seems to me to be a good compromise.

(Cue the TDD rebuttals now... :) )

После написания Следует ли тестировать внутреннюю реализацию или тестировать только публичное поведение? и обсуждая ответы людей, я думаю, что ответ может зависеть от того, сколько человек входит в команду разработчиков.

Преимущества тестирования с базой данных:

• Тестирование более реалистично (с использованием реальной базы данных)
• Меньше тестирования код для записи (не нужно писать имитацию базы данных)

Недостатки тестирования с базой данных:

• Ваши тесты не могут выполняться, пока не будет написан уровень доступа к базе данных
• Если есть ошибка или провал теста, ты неНе знаю, в вашем коде или в уровне доступа к базе данных

. Недостатки особенно важны, если (но, возможно, только если) человек, пишущий верхний уровень, не совпадает с человеком, пишущим уровень доступа к базе данных.

The problem in adressing the database in your tests is that a change in the database or a change in your code can fail the test. A unit test normally should point as direct as possible to the change that made him fail. Поэтому, если вы хотите протестировать код для доступа к БД, возможно, используйте фиксированную тестовую базу данных. Таким образом, вы уверены, что код, который обращается к БД, неверен, потому что вы знаете, что база данных не изменилась, и если вы хотите изменить настройку БД, сначала измените тестовую БД и увидите, что ваш тест завершился неудачно, затем исправьте его, а затем измените не тестовая БД. В проекте, над которым я работал, мы создали небольшую базу данных, которая была сгенерирована в памяти перед каждым тестом.

"...the database should not be hit when the unit tests run..." - unless you're unit testing persistence objects, of course.

I don't know which blogs you're citing, but I'll bet what they're saying is that mocking some components during integration testing can have benefits. If you've already unit tested the persistence tier, there's no need to test it again. The benefit of mocking in that case has more to do with reducing dependencies and uncertainty. For example, you might have unit tested your code, packaged it up, and now it's time to move it into an environment that's closer to production. If the databases you need can't be available (e.g., don't have the proper version of the schema, missing data that you need, or simply needed by another application that got there first), you can use mocks to allow your integration test to proceed without delay.