Unit Tests don't fail if any results returned

I'm trying to set up unit tesng, and it seems like the tests automatically succeed if any statement returns a resultset. Is that by design?

For example, I execute a stored proc to update some data and it returns a resultset of one row with the value "Success". I'd then expect to be able to follow that with an assertion statement like:

	Code:
	if not exists (select * from table where data = updated_value) raiserror('Data wasn't updated', 16, 1)

so that the test case would actually fail. Howevr even if the error is raised, SQL Assstant passes the test case.

Is the only way to do this to put the execute and assertion statements in separate test cases?

Here's a trivial example showing what I mean. Put this code in the Execute tab of a test case, and the test case will fail:

	Code:
	--select 1 as x; raiserror('Fail!', 16, 1);

Uncomment the first line, and the test case will pass:

	Code:
	select 1 as x; raiserror('Fail!', 16, 1);

I'm able to reproduce your results and I don't think this is the intended behavior. I'll check with the developers tomorrow morning to ensure we aren't missing anything here.

Thank you. If the devs have a pattern for creating tests that avoids this issue, please let me know and I'll happily give that a try.

This has been confirmed as a bug. A fix for that is available and will be provided in the next maintenance release 5.1. No official release time is known yet for 5.1, and it may take a while.

If you have an effective maintenance for your license, we can provide you with the latest private build which contains the referenced fix.

	SysOp wrote:
	This has been confirmed as a bug. A fix for that is available and will be provided in the next maintenance release 5.1.

I've just installed the new maintenance release 5.1.7, and the bug still seems to be there. Did the fix not make it into this release?

	SysOp wrote:
	If you have an effective maintenance for your license, we can provide you with the latest private build which contains the referenced fix.

We have an active maintenance license, but I'd rather stay with the main build sequence. This isn't an important bug, more of an irritation, so I'm willing to wait for it to come out in a fully tested production build.

Cheers,
Rick

Thank you for reporting this issue. I'm checking on the status of this fix and will provide an update as soon as possible.

It appears the handling of code execution errors is connection type dependent and there are separate fixes for unit tests error handling for different connection types. Some of them made into the initial 5.1 build, some didn't, yet.

To see it for yourself, in SQL Assistant settings enable Notepad as a target for SQL Server, change assistance type to SQL Server, change connection type to ODBC. Open Notepad, right-click choose Unite Testing, open your test project. Run it and you should see that the unit test with SELECT … RAISERROR case fails as expected.

	Quote:
	It appears the handling of code execution errors is connection type dependent and there are separate fixes for unit tests error handling for different connection types. Some of them made into the initial 5.1 build, some didn't, yet.

Ok, thanks for looking it this for me. I think I'll skip Notepad for now and wait for the fix to make it into the SSMS connection.

Cheers,

Rick

This should be fixed for all db interfaces in 5.1.10. Please update your version

This should be fixed for all db interfaces in 5.1.10. Please update your version

Yes, it now works as expected. Thank you for the quick turn around.