Isolating Dependencies

 

This group of objects enables you to isolate the are of code which you are testing. When you are unit testing a complex system, it is desirable to isolate certain parts to test. For example, if you have a complicated set of tables which are related through foreign keys, it can be very difficult to insert test data into one of the tables. The objects in this section provide the ability to focus on a single unit to test.

 Posted by at 5:22 pm
5 comments
james
james

A stackoverflow article mentions something that may work for faking functions

Lisha
Lisha

hi, I couldn't find anything about faking or appling an index after faking the table ? I am creating a test for a table and I need the presence of a filtered unique non clustered index , after faking the table,,, how can I do that ? appreciate your help. Thank you, Lisha

Vladimir
Vladimir

Hello, I writed SP that helps to fake scalar functions.It's not fully compled but it workin for me. create procedure tSQLt.FakeScalarFunction @FunctionName nvarchar(max) , @ReturnValue sql_variant = null as begin declare @Cmd nvarchar(max); declare @ProcParmTypeList nvarchar(max) declare @Seperator char(1) , @ProcParmTypeListSeparater char(1) , @ParamName sysname , @TypeName sysname; declare @fn_ObjectId bigint = object_id(@FunctionName) if not exists ( select * from sys.objects where type = 'fn' and object_id = @fn_objectId ) begin raiserror ('Scalar fucntion %s does not exists', 16, 1, @FunctionName) return; end select @ProcParmTypeListSeparater = '' , @ProcParmTypeList = '' declare Parameters cursor for select p.name , t.TypeName from sys.parameters p cross apply tSQLt.Private_GetFullTypeName(p.user_type_id, p.max_length, p.precision, p.scale) t where object_id = @fn_ObjectId and p.parameter_id > 0; open Parameters; fetch next from Parameters into @ParamName, @TypeName; while ( @@FETCH_STATUS = 0 ) begin select @ProcParmTypeList = @ProcParmTypeList + @ProcParmTypeListSeparater + @ParamName + ' ' + @TypeName + ' = NULL '--, select @ProcParmTypeListSeparater = ','; fetch next from Parameters into @ParamName, @TypeName; end; close Parameters; deallocate Parameters; declare @ReturnTypeName sysname = ( select t.name from sys.objects as o join sys.parameters as p on o.object_id = p.object_ID join sys.types as t on t.system_type_id = p.system_type_id where type in ( 'IF', 'TF', 'FN', 'FS', 'FT' ) and p.parameter_id = 0 and o.object_id = @fn_ObjectId ) select @Cmd = 'DROP function ' + @FunctionName + ';'; exec(@Cmd); declare @retValueStr varchar(max) = case when @ReturnValue is null then 'NULL' else convert(varchar(max), @ReturnValue) end select @Cmd = ' CREATE function ' + @FunctionName + ' ( ' + @ProcParmTypeList + ' ) ' + ' returns ' + @ReturnTypeName + ' AS BEGIN return ( ' + @retValueStr + ' ) ; END;'; exec(@Cmd); return 0; end; go

@sqlity
@sqlity moderator

@DaveBoltman, tSQLt currently does not offer a built in way to apply an existing index to a faked table. For tSQLt.ApplyConstraint to handle Unique Constraints is one of the next items on the backlog, but currently it is not implemented either. 

Your best bet right now is to script out the index before faking the table and then re-applying it after the fake. But that is certainly not as simple as calling tSQLt.ApplyConstraint.