tSQLt - Database Unit Testing for SQL Server

Database Unit Testing for SQL Server

  • Home
  • Docs
    • Documents
    • Quick Start
    • Articles
  • Training
  • Downloads
tSQLt » Documents » Test Creation and Execution » Run

Run

Syntax

tSQLt.Run [ [@testName = ] 'test name' ]

Arguments

[@testName = ] ‘test name’
Optional. The name of a test case, including the schema name to which the test case belongs. For example ‘MyTestClass.[test employee has manager]’. If not provided, the test name provided on the previous call to tSQLt.Run within the current session is used. If no test cases have been run previously in the current session, then no test cases are executed. Optionally, ‘test name’ may be the name of a test class. In which case all tests on that class are executed.

Return Code Values

Returns 0

Error Raised

Raises an error containing the test case statistics if any test fails or errors. For example, if a test case fails, the following error is raised:

Msg 50000, Level 16, State 10, Line 1
Test Case Summary: 117 test case(s) executed, 116 succeeded, 1 failed, 0 errored.

Result Sets

None

Overview

(Note that tSQLt requires test procedure names to start with the four letters test.)
tSQLt.Run is a flexible procedure allowing three different ways of executing test cases:
1. Providing a test class name executes all tests in that test class. If a SetUp stored procedure exists in that test class, then it is executed before each test.
2. Providing a test case name executes that single test.
3. Providing no parameter value executes tSQLt.Run the same way the previous call to tSQLt.Run was made when a parameter was provided. This essentially caches the parameter value of tSQLt.Run so that it does not need to be retyped each time.

tSQLt.Run displays a test case summary. By default, the test case summary is a text based table. However, the result format can be changed using the stored procedure, SetTestResultFormatter.

Examples

-- Runs all the tests on MyTestClass
EXEC tSQLt.Run 'MyTestClass';

-- Runs [MyTestClass].[test addNumbers computes 2 plus 2 equals 4] and executes the SetUp procedure
EXEC tSQLt.Run 'MyTestClass.[test addNumbers computes 2 plus 2 equals 4]';

-- Runs using the parameter provided last time tSQLt.Run was executed
EXEC tSQLt.Run;

See Also

Creating and Running Test Cases with tSQLt

  • DropClass
  • NewTestClass
  • RenameClass
  • Run
  • RunAll
Share and Enjoy:
  • FacebookFacebook
  • TwitterTwitter
  • LinkedInLinkedIn
  • RedditReddit
  • StumbleUponStumbleUpon
  • TechnoratiTechnorati
  • PrintPrint
7 comments
  Livefyre
  • Get Livefyre
  • FAQ
Sign in
+ Follow
Post comment
 
Link
Newest | Oldest
jeremyjsimmons
jeremyjsimmons 5pts

Please update the documentation to explicitly state that a test case is a procedure where the name meets the condtion LOWER(name) LIKE 'test%'.


the topic for runall http://tsqlt.org/user-guide/test-creation-and-execution/runall/ - already has this "The name of each test case stored procedure must begin with ‘test’".


Also, it sure would be nice to have the option to apply an extended property of tSQLt.TestCase to ANY stored procedure, even if the name does NOT start with test%, and have it be picked up.

@sqlity
@sqlity moderator 5pts

@jeremyjsimmons  thanks. Updated the page. The extended property is somewhere on the backlog but not the highest priority right now.

IldarS
IldarS 5pts

Is there a way to call a test store procedure with parameters? 

I'm testing a Function that returning 1 or 0 depends on different data set and instead of creating a separate test for each data set, I would like to use parameters.

Thanks,

@sqlity
@sqlity moderator 5pts

@IldarS , there is currently no built-in way to parameterize tSQLt tests. What I have done in the past to get around that is to write the parameterized test as a stored procedure (with a name not starting with "test"), and then write a new actual test procedure for each parameter combination that you want to test, each containing only a single statement to execute the parameterized procedure.


I know that is not quite the same, but it is probably the closes you can get for now. (Real parameterized tests are on the backlog.)

nidps
nidps 5pts

@@sqlity can you give me and example of the work around you specified,am also in the same situation,i need to create test with parameters

Texonidas
Texonidas 5pts

I'm having issues debugging a stored procedure using tSQLt. There appears to be an error occurring in the stored procedure that shows up while testing, however when I insert a breakpoint to determine what the error is, the breakpoint never triggers when the procedure is executed through a tSQLt.Run testClass call. Does tSQLt support breakpoints?

@sqlity
@sqlity moderator 5pts

@Texonidas I am not aware of incompatibilities of tSQLt with a debugger, unless you are using one of the advanced methods like ResultSetFilter. It is more likely that the error is happening in a different place than you think. 


The fact that you need a debugger points to an entirely different problem however. Your code is clearly to complex to handle. Can you break the procedure in smaller pieces, so that you do not need a debugger to understand what is going on?

Navigation

  • Full user guide
  • Why you should use the tSQLt framework
  • How to get more out of tSQLt
  • Join the conversation
  • Downloads
  • Articles
  • Release Notes
  • New Logo
  • Training
  • Sponsors & Contributors
  • Why you should unit test SQL Server Code
  • Documents
    • Quick Start
    • tSQLt Tutorial
    • tSQLt Keyboard Shortcuts
    • Test Creation and Execution
      • NewTestClass
      • DropClass
      • RunAll
      • Run
      • RenameClass
    • Assertions
      • AssertNotEquals
      • AssertEmptyTable
      • AssertEquals
      • AssertEqualsString
      • AssertEqualsTable
      • AssertObjectExists
      • AssertResultSetsHaveSameMetaData
      • Fail
      • AssertObjectDoesNotExist
      • AssertEqualsTableSchema
      • AssertLike
    • Expectations
      • ExpectException
      • ExpectNoException
    • Isolating Dependencies
      • ApplyConstraint
      • FakeTable
      • SpyProcedure
      • FakeFunction
      • RemoveObjectIfExists
      • ApplyTrigger
      • RemoveObject

Links

  • tSQLt on GitHub
  • tSQLt Mailing List
  • twitter hashtag (#tsqlt)
  • tSQLt tag on stackoverflow.com
  • SQL Server Community on Slack (#tsqlt)

Sponsors

sqlity.net
redgate.com

A sqlity.net llc Web Property. | ©2010 - 2020, All Rights Reserved. | Privacy Policy | Terms of Use