Как применить ограничение NOT NULL обратно к столбцу таблицы в tSQLt?
CREATE OR ALTER PROCEDURE [test abc].[test abc1]
AS
BEGIN
-- Arrange
EXEC tSQLt.FakeTable 'dbo', 'table1';
-- Here the NOT NULL constraint should be put back on table1 column col1
EXEC [tSQLt].[ExpectNoException]
-- Act + Assert
INSERT INTO .....
END
GO
ОП конкретно спрашивает, как это сделать в контексте модульного теста tSQLt.
Для тех, кто не знает, tSQLt.FakeTable временно заменяет реальную таблицу макетом, который имеет ту же схему, имена таблиц и столбцов, а также все те же типы данных, но без каких-либо ограничений. Таким образом, все столбцы допускают NULL, а все ключи, значения по умолчанию, проверочные ограничения и даже свойство IDENTITY удаляются на время теста. Это может быть полезно при написании модульных тестов для одной таблицы со многими зависимостями — это сводит к минимуму настройку, необходимую для каждого теста. В конце каждого теста выполняется откат транзакции, в рамках которой выполнялся этот тест, и возвращается исходная структура таблицы.
Теперь к фактическому вопросу, хотя таблица tSQLt.Fake позволяет сохранить определенные функции исходной таблицы в макете, включая автоинкремент, вычисляемые столбцы и ограничения по умолчанию, обнуляемость не является одной из этих функций. Хотя, если это читают @SebastianMeine или @dennislloydjr, такая функция может оказаться полезной.
Я не верю, что нет автоматического способа применить NOT NULL к столбцам в поддельной таблице, однако возникает вопрос о вашем варианте использования. Хотя FakeTable невероятно полезен во многих тестовых сценариях, бывают случаи, когда вам нужно запустить один или несколько тестов для реальной таблицы. Очевидным примером здесь является хранимая процедура, предназначенная для ВСТАВКИ новой строки в эту таблицу. Если новый столбец NOT NULL добавляется в таблицу после того, как была написана процедура вставки, процедура завершится ошибкой, поскольку она не вставит значение в новый обязательный столбец. Вы определенно хотели бы получить это при тестировании и иметь по крайней мере один тест этой хранимой процедуры против реальной таблицы, который обнаружит эту ошибку, прежде чем вы перейдете к рабочей среде.
Если ваш вариант использования требует, чтобы только определенный столбец был возвращен в значение NOT NULL, вы можете сделать это вручную UPDATE myTable ALTER COLUMN myColumn <datatype> NOT NULL после вызова tSQLt.FakeTable, хотя опасность такого подхода заключается в том, что если тип данных или допустимость значений NULL для этого столбца изменятся в будущем, вы не будет возможности автоматически изменить определение столбца в вашем тесте, что делает тест менее надежным.
Мне жаль, что нет простого ответа на ваш вопрос.
Попробуйте следующее:
UPDATE MYTABLE
SET MyColumn = 'Default Value'
WHERE MyColumn IS NULL
ALTER TABLE MYTABLE
AlTER COLUMN MyColumn DATATYPE NOT NULL
Потеря возможности NULL в тесте tSQLt не должна быть проблемой. Вы контролируете данные, размещенные в поддельных таблицах. Вы можете убедиться, что столбцы, требующие значений для правильного тестирования, заполнены. Изменение того, как фальшивая таблица характеризуется изменением столбцов во время выполнения теста, значительно усложняет долгосрочное обслуживание тестов.
Вы можете создать частную версию FakeTable, которая перегружает оригинал. Таким образом, вы можете автоматизировать восстановление настроек NULLability. (У нас есть довольно обширная схема расширения, которая перегружает FakeTable и реализует множество других внутренних функций без изменения базового продукта.) Недостатком этого является то, что теперь вы должны учитывать все столбцы NOT NULL при заполнении тестовых данных, что и является FakeTable. намеренно, частично, чтобы избежать. Присвоение всем столбцам значения NULL позволяет сфокусировать тест на столбцах, важных для этого контекста теста.
Вы не сказали, почему вы хотели восстановить настройки NULLability. Знание этого улучшит любые ответы.
