KellyLynch,

в чём загвоздка? нет преград для процесса написанном на C#
(или другом языке) подключится к серверу (под нужным user)
и запустить процедуру (или любую другую SQL операцию/скрипт),
дождаться окончания (в пределах настроек соединения)
и получить ответ.

KellyLynch,

вроде ведь и так по определению:
логика приложения наверняка и так в приложении,
логика сервиса (appserver) - на сервисе,
логика SQL - в SQL (процедурах)

(хотя не всегда получается изолировать и разнести по шагам из-за длинной цепи зависимостей)

пока не будет понятия о том что именно и куда выносить - разговор ни о чём.

пример 1 (больше бизнес):
не кучу параметров к вызываемой процедуре которая на основании этих параметров решает
какую (sub) процедуру вызывать
а сразу вызов нужной процедуры с меньшим количеством параметров.

пример 2 (как выше указали: целостность):
begin tran ... commit/rollback, там-же логика резерваций ID, локи и пр.

первый пример - реализуем, второй - рассыпание граблей.

в результате тесты скорее всего только покажут что лучше это делать на SQL proc
(т.е. ничего нового, что было известно заранее, много активности, негативная продуктивность)

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

KellyLynchЦели: тестируемость (получить возможность писать unit tests на C#); масштабируемость.
в чём проблема с тестируемостью из C# сейчас?
есть ограничения по масштабируемости?
C# приложение не может вызвать оду и туже процедуру несколько раз параллельно?
KellyLynchСейчас мне нужны любые советы: какие подходы и инструменты (библиотеки, framework-и и тд) могут тут помочь?PowerShell тот-же .NET / C# , без проблем и для стресс тестирования, и для логического
многие автоматизированные тесты с ним напрямую и работают

KellyLynchC# приложение написано на Visual Studio 2017. приложение написано на C# , разработано в VS

Lepsik,

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

внешний процесс может вызывать те-же скрипты (инструментарием того-же SQL) широким фронтом
разных сессий одновременно, т.е. параллельная мультизадачность в workflow
(и речь вовсе не о multithreading, т.к. это немного другая тема со своими возможностями на обоих endpoint)