I'm using Gradle for build automation. Part of my automation process is to run tSQLt unit tests on SQL Azure databases. I use SQL Groovy through a JDBC driver. A failed test will be reported back to Gradle correctly, but doesn't give any information other than how man tests failed. The tSQLt framework provides a great summary, but uses PRINT to display it in SSMS.
I would really like to redirect the PRINT summary from tSQLt (basically a PRINT command in SQL Server) to a file, or even the screen. Just so it doesn't get lost.
I may not be using the correct connection method, but to run the unit tests and have them report errors back, I use:
sqlConnection.executeUpdate("exec tSQLt.runall")
There's probably a better method that will allow me to pipe the output, but I haven't been able to find it.
Related
I'm trying to find a bug on a store procedure(SQL server) that gets executed from a console application coded in C#. Is there a way I can do some sort of breakpoints into the Store Procedure scripts and find how the data gets processed into the store procedure in real-time?
I know that you can debug a simply Stored procedure on Visual Studio. But what I want to do it's to debug it in real-time with the console application.
Dependent on which version of SQL Server you are using you will want to use either SQL Server Profiler or Extended Events, see Quick Start: Extended events in SQL Server and SSMS XEvent Profiler.
My question is this:
What is the best setup for managing SQL changes in a development team?
Our team consists of 4 developers, each with their own copy of a database.
When committing SQL/Application changes to our TFS server, we wish to ensure that any build errors do not get propagated to other developers. So, we are going to implement continuous integration to assist with this.
The idea is that
1.SQL and application code changes are committed to TFS.
2. A central database gets the SQL updates, and we build the application.
3. Unit tests are executed on the build server.
4. If any of these steps fail, the checkin is rejected and the database gets rolled back to the state it was in before the commit.
What is the best way to set up our Redgate SQL source code to implement this?
If you want to use SQL Source Control, based on your requirements this is a possible setup to consider.
For each developer machine:
Install SQL Source Control
Link each developer database to your TFS repository using Dedicated database as development model.
Install SQL Prompt to write your SQL more easily
Configure SQL Test for writing unit tests for SQL Server
On the build server:
Install Redgate DLM Automation (there are Add-Ons to simplify setup)
Configure a Validate build task to validate the schema by checking the database can be built successfully from scratch
Configure a Test build task to run SQL tests
Configure a Sync build task to update your central database with the SQL updates
Run your application unit tests
If the test fails, you can run a custom script that revert the last check-in, use the sync build task again to roll back the database changes and trigger a new build. You can use Redgate DLM Automation PowerShell cmdlets to do it.
The last step could be tricky. I honestly prefer and recommend to use branches instead of relying on a single central database. In this way, each developer can be working fully independently and you can merge the new changes in the master branch only when the work has being validated on each individual branch.
If you want to go further and also implement deployment you can use Redgate DLM Automation Deployment to create a release database package and deploy your database changes to production directly from your build server or using a release tool like Octopus Deploy.
Finally, I would also advice you to have a look at Redgate ReadyRoll especially if you are considering a migration-first approach to database changes.
As you can see, there are different ways of using Redgate tools to manage database changes and there is no single best way of setting them up. It always depends by the specific requirements and problems you need to solve.
Hope this helps.
You can use a Database Project. It can contain the entire database schema plus stored procedures. During a build, it will verify that the stored procedures match the schema.
Then enable the Gated Check-in option in build definition, it accepts check-ins only if the submitted changes merge and build successfully.
For the data written to database, it's based on your test method, you can set the method to delete the data if the test failed, or you shouldn't be writing to a real database. Instead you should mock the database classes. This way you don't actually have to connect and modify the database and therefor no cleanup is needed.
For more information you can reference below articles:
How To Unit Test – Interacting with the Database
Database cleanup after Junit tests
I am new to working with SQL database but have been confronted with testing my database. For security reasons any queries or updates are done through stored procedures.
It was suggested to me by a peer to use stored procedures to test other stored procedures. Is this a good or bad solution to unit testing my stored procedures to ensure they are doing what they are suppose to be doing?
I found an excellent solution using Visual Studio:
Visual Studio Unit Testing
It allows you to create unit tests for SQL stored procedures, you can also populate the database using regular expressions - very cool stuff.
Apart from DbUnit and NUnit you can use tSQLt if you like writing tsql. tSQLt is an open source framework written in tsql for writing unit test cases for tsql.
DbUnit from dbunit.org is a good framework. Another great tools are TSqlUnit and tsqlt from tsqlt.org.
I have been using TST as testing framework for SQL Server with very positive results.
It works well and I could even integrate it as part of our CI-environment in Team City.
The key is to be very careful on how to set up your test data. Whatever test framework you choose, be sure to apply the Test Data Builder pattern. If you don't, you may very quickly get some test refactoring problems.
I don't know the which tool can do a unit test for the SQL statements or store procedures.
I usually write the SQL script to do a test for that.
Create an empty database, of course, the same structure as the original one.
Prepare the data (import some data from the original database).
Invoke the stored procedure.
Then see the data if it's correct or not.
Sometimes write some assert statements like the
IF EXISTS (SELECT * FROM XX INNER JOIN XXX ON XXXXXXXX WHERE XXX=XXX)
RAISEERROR XXXXXX
If some exceptions or errors are thrown then you can check the stored procedure.
But it's a waste of time.
I usually check all the executing path for the stored procedure most of the time, and just test the main error expecting points.
I have been using TestContainer(Mysql) to mock mysql server.
Using Kotlin/Java JUnit5 as the test runner.
so in the test case, it will
start TestContainer
seed data that is required for the test.
execute the Stored Procedure.
assert that the data is accurate.
I am executing regression test created by selenium and triggered from hudson. After this test i need to clean up DB , so for this any option there in Hudson to connect DB and execute some script? Or what is the best way to do this one?
Thanks in advance
by Mani
There is no build-in plugin in Hudson/Jenkins that I'm aware of, but you can make the Hudson build process execute a shell script/bat file that in turn can do whatever you can do with a script:
Shell scripts and Windows Batch commands
Depending on your situation it might be preferable to add this step to an overall build script (as an <exec> task in ant for example).
You can do as stated above or if you connect to the databases using JPA or Hibernate you can set up those so the database is recreated each time. That's how I do it on my case. From the question is hard to tell which method you use to connect to the database.
My tests are being invoked through TestNG and before they run, I clean up the DB via JDBC.
Since you didn't say which DB you are using, I recommending Googling for "[DB] JDBC example", changing [DB] for whatever DBMS you are using :)
Has anyone come across any good tools (preferably but not necessarily FOSS) that can read a SQL Server (2005/2008) trace file and execute the commands against another database. We are attempting to perform some performance testing on our SQL servers and would like to replicate an actual load.
I have come across but not yet used:
JMeter
ReplayML
Preferably, the application would be able to use threading to mimic user connections and query execution on the SQL Server.
You can replay a SQL Server Profiler trace against another server using the SQL Server Profiler itself.
See the following Microsoft Reference as a starting point.
http://msdn.microsoft.com/en-us/library/ms189604.aspx
Quest Software also have a tool called Benchmark Factory that can be used to perform SQL Server load testing.
http://www.quest.com/benchmark-factory/
One of the best tools is actually freely available from Microsoft. The RML Utilities are targeted at SQL2005 & SQL2008 and are specifically designed for this type of testing.
You can download the tools from http://www.microsoft.com/downloads/details.aspx?FamilyId=7EDFA95A-A32F-440F-A3A8-5160C8DBE926&displaylang=en
We have used them to solve several performance and locking issues.
Note: Capturing trace files using the SQL Profiler GUI can add to performance problems due to the way the GUI and Trace backend interact. The RML Utilites include a script that can capture traces directly from the SQL Server without using the GUI.
You can replay trace files directly in SQL Profiler, although I've only used it a couple of times for that, so I don't know what all of the limitations are on it.
team system has an add-on that you can find on codeplex: It is called ->
sql load test
Let me know if that works well for you.
I know this is a really old question but after searching for some time i discovered a new open source tool.
https://github.com/spaghettidba/WorkloadTools which works great