UnitTest用にDBの枠組みから毎度毎度作り上げるようにしているのですが、そうそうCreate Databaseからやっているときりが無いので、1回のテストの流れではDatabaseの作成は1回にとどめています。
その分テストの1回ごとに元の状態に戻してやる必要があります。
IdentityがSQL Serverの特徴ですので、基本的にはIdentity列を使うことにしているのですが、これの初期化にはDBCC CHECKIDENT を使います。
ただしこれ1度もテーブルにInsertされていない場合と、InsertしてからDeleteして再設定するときでは動きが違います。
CREATE TABLE [#Table_1](
[ident] [int] IDENTITY(3,1) NOT NULL,
[val] [nchar](10) COLLATE Japanese_CI_AS NULL
) ON [PRIMARY]
--いきなりCHECKIDENT
DBCC CHECKIDENT ('#table_1', reseed, 1)
insert into [#table_1](val) values('めいしょう')
insert into [#table_1](val) values('めいしょう')
select * from #table_1
--一度データを設定したものを削除して最INSERT
delete [#table_1]
DBCC CHECKIDENT ('#table_1', reseed, 1)
insert into [#table_1](val) values('めいしょう')
insert into [#table_1](val) values('めいしょう')
select * from #table_1
drop table [#table_1]
DBCCからINSERTしてSELECTの流れはまったく一緒のSQLですが、結果はまったく違います。
1 めいしょう
2 めいしょう
2 めいしょう
3 めいしょう
このように結果が違います。
なにもINSERTしない状態ではDBCCした直後にはそのDBCCで設定した値がそのまま使われますが、1度でもINSERTしていると１の次の値の2から利用されます。
DBCC CHECKIDENT の仕様を見る限り最大値を設定しますとのことなので、最初の動きがおかしいのは明白ですが、これはIdentity Seedが一度も設定されていないからnullに成っているのが原因と思われます。
でもnullは設定できないので不公平です。
こんなのおかしいよと思う人が1人でもいれば、MSDN Product Feedback にKatmai用にWishをあげたいと思います。どうでしょ？
#でもnullの時の動きが変わるとそれはそれで困るかもしれないんですがね～
単体テストする場合には事前に、またはCreateDatabaseするときに、一度ダミー行をINSERTして、Deleteしてまわって、DBCC CHECKIDENTしてまわるようにするといいと思います。