0

我是 sql 单元测试的新手，但我已经编写了我的第一个测试并试图确保这是一个合理的测试。所以我有一个存储过程，它执行简单的更新（如果存在）或插入（如果不存在）。使用 TSQLUnit，我编写了下面的测试来测试我的名为spModifyData的存储过程。测试的目的是验证当现有 ID 通过时，不会在数据库中创建新记录。

ALTER PROCEDURE [dbo].[ut_TestspModifyData] 
AS
BEGIN 
    SET NOCOUNT ON;
     -- Setup the test conditions by inserting test data
     DECLARE 
                @newidone uniqueidentifier,
                @newidtwo uniqueidentifier,
                @newidthree uniqueidentifier,
                @ExpectedID uniqueidentifier,
                @ActualID uniqueidentifier

                SET @ActualID = '13E7C741-9A04-4E84-B604-141874A6A9B4'
                SET @ExpectedID = '13E7C741-9A04-4E84-B604-141874A6A9B4'
                SET @newidone = newID()
                SET @newidtwo = newID()
                SET @newidthree = newID()

                 INSERT INTO DataSource( [DataSourcePrimarySource],[DataSourceName],[DataSourceRecordCreateDate] 
          ,[DataSourceStatus] ,[DataSourceIsActive]) VALUES ('PRIMARY SOURCE ONE', 'XYZ', GETDATE() , @newidone, 1)

  -- Exercise the test
 EXEC  spModifyDataSource @ActualID , 'PRIMARY SOURCE ONETWO', 'BBB', @newIDone, 0  

 -- Assert expectations
 IF (@ExpectedID != @ActualID)
                EXEC dbo.tsu_Failure 'ModifyData failed.' 

-- Teardown
 -- Implicitly done via ROLLBACK TRAN

END
4

1 回答 1

0

As this test is testing a functional part of your stored procedure, then yes it is a "sensible" unit test - it doesn't have to test parameters to be valid.

That being said - I'm not sure it's the best way of testing what you are trying to. You appear to be using @ActualID as a variable which you set early on but don't specify as an OUTPUT parameter, so I would always expect this test to pass (either I'm reading that wrong, or there's a bug in the test).

Your question stated your test aim was : "verify that when an existing ID is passed, a new record is not created in the database."

I would actually approach the assert section of this test slightly differently - I'd check the result in the DataSource table directly rather than checking the returned parameter - as you are then checking what's created in the database. I would additionally check any output parameter, but usually I'd regard output parameters as a separate test to data checks, or at least a separate assert - and therefore separate message - in the test.

I think you will find it helpful if you can use more descriptive messages - as per the example in the TSQLUnit cookbook

I find it easier to resolve tests that only test one thing - and therefore I know what needs to be fixed. They are often simpler to write, too!

Does that help?

于 2012-08-29T06:11:14.900 回答