When unit testing code there is a really powerful feature that is either called mocking or faking or sometimes using stubs and what these mean is creating objects that look like real objects but aren’t. Why would you want something that looks like something but isn’t? Unit testing means breaking your code into small chunks and testing that the small chunk does what it is meant to. Testing small chunks of code in isolation is difficult as they often call other chunks of code so we test and pretend that the other thing is correct and to validate those other small chunks, we unit test them.
I recently had the chance honour to spend twenty minutes talking to Boris Hristov about testing with Sql Server for his Google Hangouts series, catch the video here One of the things I mentioned was that having a suite of unit tests helps to document the code and in this post I would like to demonstrate that. If we take the first stored procedure in the AdventureWorks2012 database to see how it is documented, if we take the procedure definition, we get:
I was asked an interesting question about collations in sql server recently about where variables in a script got their collation’s from. I really wasn’t too sure of the answer, I generally try to ensure that databases are in the company default collation although I realise that this is not always possible. Given how important this is I thought I would investigate it a little: The first question I had was what collaction is the actual T-Sql script compiled in, is it the database or server?
I have worked as a DBA and also as a Sql Server developer and in many roles had full access to production, it is OK though I know what I am doing and I normally don’t make mistakes (we’ll come back to this!). To be clear, this isn’t a moan at DBA’s, I am one and can and do make changes myself - I am trying to improve processes that I have input into.
There has been a gigantic shift in attitudes between development and operations, the devops movement, to create a streamlined, automated and high performing team of developers and infrastructure techs which has really helped transform many operations and projects. It occurs to me that when building a development team or planning out a project we should include resources for developers to write tools and improve processes for the other developers in the team.
There has been a gigantic shift in attitudes between development and operations, the devops movement, to create a streamlined, automated and high performing team of developers and infrastructure techs which has really helped transform many operations and projects. It occurs to me that when building a development team or planning out a project we should include resources for developers to write tools and improve processes for the other developers in the team.
I have moved my blog over to here, expect exciting posts about the things that interest me my previous blog was at: http://sqlserverfunctions.wordpress.com. I hope you find something you enjoy and please comment or contact me for anything! Ed
When you deploy an SSDT project to a database, the overall process looks like: Dacpac is compared to the database SSDT generates a list of opertations it needs to do to make the database the same as the dacpac SSDT has some options like “IgnoreWhitespace” and “IgnoreObjectNameCase”, these are applied to see if the list of operations can be pruned SSDT then runs any pre-deploy scripts from the dacpac SSDT then runs the code it generated for each operation SSDT then runs any post-deploy scripts The database is the same as the dacpac The important thing here which isn’t entirely obvious is that the pre-deploy script is run after the list of things that SSDT needs to do has been generated.
