Redgate SQL Test utility isn’t showing up in SSMS

I had recently installed the SQL Toolbelt from Redgate at a client site on a laptop they’d supplied me.

(Fantastic product that SQL Toolbelt BTW.)

Things were going swimmingly – in fact thanks to SQL Compare, SQL Source Control and Team Foundation Server I had implemented an automated Continuous Delivery pipeline for the clients databases and applications.

The next thing I wanted to do was start implementing unit testing for both the applications and database. DEV were going to do the application side (this client is a start-up so it made sense that they had little to no unit tests) and I’d do the database side.

Except in SSMS I couldn’t find SQL Test…??

Redgate SSMS SQL Source Control
Where is SQL TEST?

I knew to click on the icons to bring down other utilities but it wasn’t here either:

Redgate SSMS Where is SQL TEST
Not here either…. what have I done wrong??

So as a windows user I naturally looked in the Windows Apps:

Redgate No SQLTEST in apps
Hmmm…. nothing here either

At this point I decided it had to be my machine as I did a google and looked on forums and no one seemed to have experienced this.

So I uninstalled everything – SSMS and the Toolbelt.

Reinstalled everything.

And got this:

It was while clicking around like a madman I found this:

Redgate Found SQL Test
FOUND IT!!!

Phew.

And of course now I can do this:

Redgate Now in my happy place
Let’s start unit testing!!

 

So if you have recently installed Redgate SQL Toolbelt and can’t find SQL Test – hopefully this blog post will help you.

By the way I do think there was something wrong with the laptop the client gave me as now when I right click I get the ability to run tests:

Redgate SQL Test context menu
This was definitely not there before the uninstall/reinstall fiasco

So now I can start my unit tests – the good news the DEV team have started theirs and are really getting behind it. I think they’ve got on with it to stop me talking about unit tests…!!

We now have 4 minutes of unit tests per checked in build but that is definitely something I’ll respond to with:

Yip.

Advertisements

Automation and cleaner code/data are the key to future success

Doing DevOPs for your Database? You need to start here…

This month’s T-SQL Tuesday #100 is hosted by Adam Machanic (B | T) who started T-SQL Tuesday 8 years ago and has invited the community to look forward 8 years at what will be T-SQL Tuesday #200…

 

Before I do that though – I want to think about what I was doing 8 years ago. At the time I was working with Object Orientated databases and the company I worked for had just implemented extensive unit testing across our technology stack. I use that word because we had both the database and application code going through unit tests, integration tests and regression tests. Most of which was automated.

It was around this time that I was starting to do more things in SQL Server, namely SQL Server 2005, funny how 7 years later I was still doing some things in SQL Server 2005 – but that is for another blog post…

It was when I came across to the SQL Server world that I realised that 2 things were different:

  1. Database build/code definitions were not in source control
  2. Unit testing was almost non-existent
  3. Automated testing or deployment was also not a common thing

Even now in 2018 I find that when speaking at conferences and I ask the questions:

  1. Who here uses source control – 60% of hands go up
  2. Who here puts there database into source control – 50% of those 60% of hands go down…..
  3. Who here does automated testing across their databases – another 50% of those hands go down

I generally get ~30 people in my sessions so if at best 5 people out of 30 are doing this – we need to change this.

Yet…

For years people have been discussing both getting our database code into source control and unit testing has been discussed at length during the past 8 years.

So what does this mean for the next 8 years?

I’m on a personal crusade to bring automated testing and DevOPs philosophies to your database…

In fact I am hoping that DevOPs doesn’t exist in 8 years time – we as an industry matured and called it “commonsense“.

Let’s talk about automation – as whilst people might not see the value in testing our most precious resource – data – they will hopefully see the light in that the more we can automate the better our jobs will be.

But won’t it kill the DBA off I hear some of you ask.

No.

It won’t.

In 2026 the role of the DBA will have morphed, in fact all Data Professionals will have an appreciation and understanding of how to automate the delivery of value to the end user. I choose my words carefully – too often we as technical people thing about 1s and 0s but in fact it is how we deliver value to our clients that dictates our success. In terms of customer experience we need to ensure we are delivering value of higher value than our competitors.

Many people are worried that automation will put them out of a job. This won’t happen, and in fact there will never be a shortage of work to do in a successful company. Rather, people are freed up from mindless drudge-work to focus on higher value activities.

This also has the benefit of improving quality, since we humans are at our most error-prone when performing mindless tasks.

By utilising the features in SQL Server Data Tools (SSDT) Version 2026 – which does both State based AND Migration based deployments to databases automatically means that we as DBAs can start focusing on activities that bring value to our clients. Databases have been touted to be self tuning for decades but I simply don’t see it happening and we need DBAs that can tune queries, and more importantly understand how automation can make their lives better.

Data Science is big time in 2026 – the past 8 years have seen a massive jump in it’s usage. This is where Data Professionals have a massive part to play – cleaning up the underlying data – who knows – through automated cleansing jobs that self tune themselves… automatically.

See where I’m going with this — the growth of data we will see over the next 8 years means we need to be more vigilant in the ways that we interact with the data.  Using automation and more testing means that the data scientists can focus on what they’re good at – doing stuff with data that they don’t have to spend (up to) 60% of the time trying to cleanse.

I am not scared of automation putting me out of a job, I’m more scared that over the next 8 years that people won’t embrace it enough to  help with the delivery of value to the end user.

Yip.