Press "Enter" to skip to content

Category: Testing

Storage Load Testing SQL Server

Anthony Nocentino designs a test:

I’ve been doing storage load tests for SQL Server for a long time, both as a consultant and now in my work at Everpure, and I see the same patterns over and over. Someone spins up a VM with two vCPUs, points it at a storage subsystem (cloud or on-prem), runs a thousand threads at it, and then concludes that the storage stinks. Or the opposite, where they buy a 64 gigabit HBA, plug it into the wrong PCIe slot, and wonder why they’re leaving half of the capacity on the table.

Designing a good load test isn’t about pushing the biggest number you can find. It’s about knowing what your gear is supposed to do, driving load until you find the point where the system breaks down, and measuring at the right places along the way. In this post, I’m going to walk you through how I think about designing a storage load test, the tools I reach for, and the pitfalls that will invalidate your results if you’re not paying attention.

Click through for Anthony’s thought process.

Leave a Comment

Testing Your SQL Server Backups

Vlad Drumea stresses the need to test:

Folks think that if they just take backups regularly, and their backup intervals match their recovery point objectives, then they can rest assured knowing (more like falsely thinking) they have backups from which to restore in case something bad happens to a database or to the entire instance.

Yeah, there are several things that can go wrong, even beyond the solid answers Vlad provides. Think about developers taking one-off backups that break the log chain, overly-aggressive purge processes that delete backups before they’re fully moved to long-term storage, etc.

Definitely check out Vlad’s post. If you’re interested, I also have a video series on YouTube that covers SQL Server backup and restore.

Leave a Comment

Unit Testing DAX via Semantic Link

Jens Vestergaard writes a test:

Every BI developer has felt it. You change a measure, update a relationship, or rename a column in a semantic model, and then you spend the next hour clicking through report pages to check if something broke. Manual spot-checking is how most teams validate DAX today. It works until it does not.

I have been building and maintaining semantic models for years. The further I get into Fabric-based development, the more my models start to feel like production code. They power dashboards that drive decisions. They feed downstream pipelines. When something breaks, the blast radius is real. And yet, the testing story has always been: deploy, open the report, squint at the numbers.

That gap bothered me enough to do something about it.

Click through to see what Jens has done.

Comments closed

Fixtures in Pytest

Jason Yousef shows off a capability in Pytest:

Pytest is one of those tools that feels obvious after you’ve used it for a bit. Tests are just functions. Assertions read like normal Python. And when you need context—database sessions, config, mock data—you reach for fixtures instead of duct tape.

Read on to see how they work. Admittedly, I don’t think I’ve used fixtures before in Pytest, but now seems like a good time to try it.

Comments closed

Coding against the Happy Path

Andy Brownsword thinks about successful code:

A common time to revisit old code is when something breaks. I was contemplating Pat’s question this week when a field length change had caused a truncation issue in an old SSIS data flow. Some code doesn’t age badly because it’s wrong, but because it didn’t expect to fail.

It’s all too easy to write a piece of code which ‘does the thing’, run a few variant tests, and send it on its way. But will it stand the test of time? That’s where my good and bad code diverge, and I usually revisit the code and find the old milk.

Admittedly, I’m not as good at this as I should be either. It can be a challenge to think through the possible issues that could arise and develop code to mitigate or eliminate those issues. But as Andy points out, it can be critical to success.

Comments closed

Workload Simulation in PostgreSQL

Dave Page announces a new load testing tool:

Most database benchmarking tools focus on raw throughput: how many queries per second can the database handle at maximum load? Whilst this is valuable information, it tells us little about how a system will cope with real-world usage patterns.

Consider a typical e-commerce platform. Traffic peaks during lunch breaks and evenings, drops off overnight, and behaves differently at weekends compared to weekdays. A stock trading application has intense activity during market hours and virtually none outside them. These temporal patterns matter enormously for capacity planning, replication testing, and failover validation.

Click through for more information, as well as a link to the pgEdge Load Generator GitHub repo.

Comments closed

Releasing a tSQLt Test Adapter for VS2022 and Later

Ed Elliott has been busy:

I have had a number of requests for me to update the tSqlt Test Adapter over the years so it would work with more recent versions of Visual Studio. I finally got around to doing this and I am pleased to say that the new version works with VS 2022, 2025 and should continue to work in future releases.

Between Visual Studio 2017 and 2019 the changes required were minimal but between 2017 and 2022 the changes meant a rewrite of the test adapter visual studio integration parts which meant it wasn’t a simple change.

Read on for information on how to install and use the extension.

Comments closed

Creating Test Data in Python via Faker

Brendan Tierney generates some artificial data:

A some point everyone needs some test data for their database. There area a number of ways of doing this, and in this post I’ll walk through using the Python library Faker to create some dummy test data (that kind of looks real) in my Oracle Database. I’ll have another post using the GenAI in-database feature available in the Oracle Autonomous Database. So keep an eye out for that.

Faker is one of the available libraries in Python for creating dummy/test data that kind of looks realistic.

Brendan generates some demo customer data, including an example of credit rating that allows for assignment of probability for each class.

Comments closed

Regression Testing for PostgreSQL Queries

Radim Marek announces a new project:

This is where RegreSQL comes in. Rather than trying to turn SQL into something else, RegreSQL embraces “SQL as strings” reality and applies the same testing methodology PostgreSQL itself uses: regression testing. You write (or generate – continue reading) your SQL queries, provide input data, and RegreSQL verifies that future changes don’t break those expectations.

The features don’t stop there though – it tracks performance baselines, detects common query plan regressions (like sequential scans), and gives you framework for systematic experimentation with the schema changes and query change management.

Read on to learn more about how it works and check out the GitHub repo if you’re interested.

Comments closed