It's a standard pattern.
- Wrap a more complicated set of methods to hide their complexity, such as a set of methods which only return errors via thrown exceptions.
- Handle errors, exceptions, etc. in the wrapper methods
- Make the methods static to prevent multiplication of derived methods like executeQueryByInt, executeQueryByLong, executeQueryByString, ...
- Limit the propagation of references to the SQL handling framework code to only the wrapped methods
- important Have a single place to document how to call, errors, special cases, bug workarounds when using the third party static library
For unit testing, your unit tests should implement a short wrapper class which only passes through calls to the static class.
There's no need to add another layer of complexity, no matter how simple, to just fit an arbitrary pattern or cloud your code. Your production code should not implement extra code just if that code is used in unit tests.
It's common to wrap a library or nuget package in a project by itself so that a multi-solution project does not have dozens of package references to a third party package.
Odd how Angular has the concept of a barrel, yet .net core has none; and you get into Nuget Package h*ll once the number of projects is more than 10 and the solution is older than 2 years.
Having restructured 1,000,000+ line .net solutions multiple times, static methods and static classes make the code easier to move around in the larger context. What best practices scale well at smaller projects do not scale well for 1,000,000+ line systems. It's a different approach than found in toy projects and short blog entries. It's about being able to see what code is called and where the code is called so that refactoring, simplification is easier.