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
This website stores cookies on your computer.
These cookies are used to improve your website experience and provide more personalized services to you, both on this website and through other media.
To find out more about the cookies we use, see our Privacy Policy