August 8, 2018 at 7:43 am
Is it possible to force a case sensitive comparison?
ie. i want this to fail:
EXEC tsqlt.AssertEqualsString 'Test','test';
August 8, 2018 at 8:57 am
Use a case sensitive collation in your test. It's simple enough that you really don't need a stored procedure.
SELECT CASE WHEN 'Test' = 'test' COLLATE Latin1_General_CS_AS_KS_WS THEN 1 ELSE 0 END
Drew
J. Drew Allen
Business Intelligence Analyst
Philadelphia, PA
August 8, 2018 at 11:32 am
Thanks, but I am trying to do this using the tSQLt testing framework. I guess I can work around it, by saving the result of the above and asserting a comparison to that, if it's a limitation of the framework procedure.
August 8, 2018 at 12:11 pm
leeholden - Wednesday, August 8, 2018 11:32 AMThanks, but I am trying to do this using the tSQLt testing framework. I guess I can work around it, by saving the result of the above and asserting a comparison to that, if it's a limitation of the framework procedure.
May not be a limitation of the framework. What is the collation used in the database you are doing the testing?
August 8, 2018 at 1:18 pm
The collation is Latin1_General_CI_AS, but I've created a function that camel cases the input, so the test needs to check the casing.
the rest of my test code looks something like this
DECLARE @expected VARCHAR(100), @actual VARCHAR(100);
SET @actual = dbo.ToCamelCase('my test value');
SET @expected = 'MyTestValue';
EXEC tSQLt.AssertEqualsString @expected, @actual;
There for the value of 'mytestcase' should return failed.
Maybe this will work?
DECLARE @expected VARCHAR(100), @actual VARCHAR(100);
SET @actual = dbo.ToCamelCase('my test value') COLLATE Latin1_General_CS_AS;
SET @expected = 'MyTestValue' COLLATE Latin1_General_CS_AS;
EXEC tSQLt.AssertEqualsString @expected, @actual;
August 8, 2018 at 2:38 pm
leeholden - Wednesday, August 8, 2018 1:18 PMThe collation is Latin1_General_CI_AS, but I've created a function that camel cases the input, so the test needs to check the casing.the rest of my test code looks something like this
DECLARE @expected VARCHAR(100), @actual VARCHAR(100);SET @actual = dbo.ToCamelCase('my test value');
SET @expected = 'MyTestValue';EXEC tSQLt.AssertEqualsString @expected, @actual;
There for the value of 'mytestcase' should return failed.
Maybe this will work?
DECLARE @expected VARCHAR(100), @actual VARCHAR(100);SET @actual = dbo.ToCamelCase('my test value') COLLATE Latin1_General_CS_AS;
SET @expected = 'MyTestValue' COLLATE Latin1_General_CS_AS;EXEC tSQLt.AssertEqualsString @expected, @actual;
We can't answer this without knowing the definition of tQSLt.AssertEqualsString.
Drew
J. Drew Allen
Business Intelligence Analyst
Philadelphia, PA
August 8, 2018 at 3:21 pm
drew.allen - Wednesday, August 8, 2018 2:38 PMWe can't answer this without knowing the definition of tQSLt.AssertEqualsString.
Drew
It's not mine, it's part of the tSQLt Testing Framework: https://tsqlt.org
The question is specific to the framework, not a general T-SQL question. Just thought someone here may have had experience with it.
August 8, 2018 at 6:13 pm
leeholden - Wednesday, August 8, 2018 3:21 PMdrew.allen - Wednesday, August 8, 2018 2:38 PMWe can't answer this without knowing the definition of tQSLt.AssertEqualsString.
Drew
It's not mine, it's part of the tSQLt Testing Framework: https://tsqlt.org
The question is specific to the framework, not a general T-SQL question. Just thought someone here may have had experience with it.
the documentation says nothing either way about case sensitivity, so I went to look at the source code at https://github.com/tSQLt-org/tSQLt/blob/master/Source/tSQLt.AssertEqualsString.ssp.sql
looks like it literally checks @Expected = @Actual, so it's about how the SQL operator compares string values.
-------------------------------------------------------------------------------------------------------------------------------------
Please follow Best Practices For Posting On Forums to receive quicker and higher quality responses
August 9, 2018 at 1:26 am
You could always extend tSQLt by writing your own case-sensitive assertion. It's just a stored proc.
Then you could callEXEC tSQLt.AssertEqualsStringCS @expected, @actual;
August 9, 2018 at 4:18 am
DesNorton - Thursday, August 9, 2018 1:26 AMYou could always extend tSQLt by writing your own case-sensitive assertion. It's just a stored proc.
Then you could callEXEC tSQLt.AssertEqualsStringCS @expected, @actual;
This was my next thought too - thanks
August 9, 2018 at 9:09 am
I think it may come down to the collation of the database where these tests are being run.
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply