Press "Enter" to skip to content

Category: Testing

Testing AI Agent Skills

Eugene Meidinger and Ruben Van de Voorde try things out:

Writing a skill takes time, and skills are context that can help but also hurt the quality of the agent’s work. So how do you know if a skill actually helps? You can test it with evals. An eval is a prompt that you re-run under the same conditions, so that the only variable is what you deliberately change. You use the same model, starting context, and the same files (and wipe leftover memory from previous attempts). Then you compare: before and after an edit, with and without a skill, or two versions of a skill. Agents are non-deterministic, so you have to run the comparison multiple times to get a reliable difference; a few runs per condition is enough to start. Decide how a run is scored before looking at the results: use objective checks where you can (did it run the right command?), and for subjective calls write down beforehand what a good answer must include. Also run in a clean workspace: if the solution is already in another branch, the baseline run isn’t a real test. Some companies run large automated eval suites, but a few saved prompts and some notes are enough to start.

Click through for a testing technique and a warning around relying on a generative model to do the work for you.

Leave a Comment

Testing Fabric Data Agent Accuracy and Determinism

Marc Lelijveld trusts but verifies:

Over the past year, I’ve written quite a bit about Fabric Data Agents. From configuring them and preparing Semantic Models for AI, all the way to deploying Data Agents using the Data Agent SDK. But once you start moving Data Agents beyond experimentation, another question quickly becomes relevant: “How do you actually know whether your Data Agent continues to return the right answer?”

Of course, you can open the Data Agent, enter a prompt and manually validate the response. That works perfectly fine while experimenting with a handful of questions, although it can already become quite time-consuming. Now imagine having to validate 20, 50 or maybe hundreds of questions, and not just once, but every time your data, Semantic Model, Agent Instructions or other parts of the solution change.

There is another aspect to this. With generative AI, we don’t only care about accuracy, but also about determinism. If we ask the same question again, can we rely on the Data Agent to consistently produce the expected outcome? This is where automated testing becomes increasingly important.

Read on to see how you can work toward answers for both.

Leave a Comment

Load Testing Azure SQL Database (Again)

Reitse Eskens is back in the fight:

When I started hammering Azure SQL again, I had a set of scripts to run and tried to figure out what was happening. For most databases, I could explain the results, but some didn’t make sense. I’ll get back to that later in this series.

A few years ago, I did a similar performance-testing series, where I created the data on the database itself using SqlStress to run a massive load of queries and see what happened. This gave a lot of interesting results, most of which are still valid, but I wanted to try something different.

After a look at some Standard SKUs, Reitse moves up to Business Critical:

My previous post on load testing Azure SQL covered the Standard Edition; today I’m moving to the Premium Edition, which is Business Critical in DTU shape.

Again, the calculation mixes CPU, Memory, and disk I/O. The main difference between Standard and Premium is cost. Premium is more expensive and aimed at mission-critical workloads. It has faster storage and built-in replication options. It also includes redundancy, with features designed to keep your solution online.

There are some interesting cutoff points in the tests that make a low-end P-SKU cheaper and just as good as a higher-end S-SKU.

Leave a Comment

Power Query Linting for Code Coverage

John Kerski has an update to pql-test:

Several years ago, I wrote a blog article introducing the concept of code coverage for semantic models: Part 8: Bringing DataOps to Power BI. With the state of Power BI technology at the time, the bridge was a little far and implementation was quite arduous.

That has changed. With Power BI Project files and User-Defined Functions becoming generally available in 2026, we now have detailed inspection possibilities with what tests exist, what specifically is being tested, and where the gaps in testing live.

I’m happy to announce that version 0.1.18 of pql-test introduces our first attempt at code coverage for semantic models: pql-test code-coverage.

Click through to see what’s new, as well as links to pql-test and more.

Comments closed

Automating SQL Server Benchmarking via HammerDB and Docker

Anthony Nocentino makes an announcement:

I’m excited to announce the release of a new open-source project that fully automates HammerDB benchmarking for SQL Server using Docker. If you’ve ever needed to run TPC-C or TPC-H benchmarks multiple times, you know how time-consuming the manual setup can be. This project removes the hassle and gets you up and running a single command: ./loadtest.sh.

Click through to learn more and to grab the code.

Comments closed

Test and Validate Azure SQL Database Migrations

Marlon Ribunal has a tool:

Introducing azsql-migration-test, a small open-source CLI that validates your Azure SQL Database migrations against a local Azure SQL Database Developer container — the same engine as the cloud, running on your machine.

The problem: proving a migration works shouldn’t require the cloud

The tool is AI-generated and it looks like the blog post is as well, but it does look to be useful.

Comments closed

Snapshot Testing in R

Jakub Sobolewski drills into a particular form of testing:

Snapshot testing is not about screenshots.

Most people meet it through UI regression tests: render a component, save a picture, fail the build when the picture changes. So the technique gets filed away as “the thing that compares images.” That is one use. But not the only one.

The mechanic underneath is general. Capture some output, save it to a file, and on every later run compare fresh output against the saved copy. The output can be a plot. It can also be console text, a log, a data frame, an error message, or a deeply nested list. Anything you can serialize, you can snapshot.

Read on to see how you can perform snapshot testing, using examples in R to demonstrate. H/T R-Bloggers.

Comments closed

Trusting Outputs from Fabric Data Agents

Jens Vestergaard says don’t trust, do verify:

In two previous posts I went down the path of getting a semantic model ready for AI: descriptions on every measure, an instructions file, the schema tidied up enough that a Fabric data agent has something real to read. That work has a satisfying endpoint. The model looks ready.

Ready is not the same as right.

The kind of evaluation Jens is talking about is fundamental to good business intelligence practices, regardless of whether you throw language models into the mix. Where language models do add complexity is the arbitrary scope of questions, how ambiguous people tend to be when writing, and the stochastic nature of answers. All of that makes the problem harder, though at least it isn’t an entirely different class of problem to solve.

Comments closed

User-Defined Functions and Power BI Testing

John Kerski is excited:

User Defined Functions (UDFs) are, in my opinion, the biggest update to Power BI Desktop since PBIP.

That may sound dramatic, but if you care about DataOps, semantic model quality, and reusable development patterns, UDFs fundamentally change what is possible with DAX.

Reuse is one of the core principles of DataOps. For years we have been able to build reusable patterns in Power Query, PowerShell, Python, YAML, and infrastructure automation. But DAX was always missing a key capability: reusable logic that could live inside the semantic model itself.

Until now.

Read on to learn more, as well as to get a link to John’s PQL.Assert DAX unit testing library.

Comments closed

Testing SQL Code in Python

Jamal Hansen writes some tests:

I once had a query that ran fine for months. Then someone added a column to the source table and a SELECT * downstream started returning unexpected data. The query didn’t error. It just silently gave wrong results. A test would have caught it immediately.

Schema changes break queries silently. Refactoring a CTE can shift results in ways you don’t notice. New data patterns expose assumptions you didn’t know you made. SQL deserves the same testing discipline as the rest of your code, and Python makes it straightforward.

PyTest, the library Jamal uses here, is one of my favorites for this kind of work. You can build up tests without a lot of ceremony and it’s pretty easy to deal with for most use cases.

Comments closed