tSQLt - How to output a custom failure or success message? - tsqlt

We are using the tSQLt framework and have the below code in the test.
IF #count>0
EXEC tsqlt.fail;
else EXEC tSQLt.AssertEquals 1,1;
I am interested to know how we can display a custom test success or failure message when this test gets executed?

tSQLt.fail takes up to 10 parameters that all get concatenated into a custom failure message.
You also do not need the call to tSQLt.AssertEquals as it, in your case, literally does nothing.
BTW, asserting a count is in almost all cases a bad idea, as it does not really tell you anything about the result. If you get the correct count back, you could still have wrong data. And if you get the incorrect count, you don't have any additional info on what went wrong.
Have a look at tSQLt.AssertEqualsTable or tSQLt.AssertEmptyTable instead.

Related

Raising Alerts from Application Insights log based on percentage?

I can write a query in application insights that gives me a percentage as a scalar. I want to create alert if that percentage is > X . How can this be done using log based alerts?
Basically, I have a lot of machines that send telemetry to application insights. Sometimes they log some exceptions. I send MachineName in customDimensions for all the logs. So I can get the names of all the machines that sent logs in last 24 hours. The exceptions are also sent with MachineName in customDimensions. When a particular error is raised by more than X% machines in last 24 hours, I want to raise an alert.
The way to write alert logic is using 'Number of Results' which cannot be used for this since it automatically adds '|count' to the query. The other way is using 'Metric Measurement', which I am guessing should help me raise an alert like this but I'm unable to figure out how.
I can get the total machine count by this query:
let num_machines = traces
| summarize by tostring(customDimensions["MachineName"])
| count;
I can get the number of machines that reported an exception like this:
let num_error_machines = exceptions
| where customDimensions["Message"] contains "ExceptionXRaised"
| summarize by tostring(customDimensions["MachineName"])
| count;
finally, i can get the percentage of machines that raised the issue like this:
print toscalar(num_error_machines)*100/toscalar(num_machines)
I am not sure how to use this result to raise an alert using MetricMeasurement. This needs to be modified somehow to get AggregatedValue and use bin, I am not sure if that is possible / how that query will be.
Sorry for the late reply. I've tested in my side and met many problems indeed.
I found that alert rule doesn't support to monitor the percentage number of the result, it only supports the numbers of query result and Metric measurement. So I think you may give up the percentage and use the num_err_machine like the screenshot below
Pls note, you can't append " ; " at the end of the query or it will give an error like The request had some invalid properties

What is the difference between Do and Do on error in Progress 4gl?

I have observed that in both cases, statements under these two blocks will execute the same. I do not understand what the difference is. Please can you explain.
Not surprisingly ON ERROR has to do with error handling. You should read up on this in the online help/manual since there's lots of ways on what to do.
DO is basically just a block. Without anything else it really doesn't do a lot. Paired with statements like TRANSACTION or ON ERROR it can greatly change how your program executes. You should check out the NO-ERROR statement as well. It also effects error handling.
In the below examples I force an error by trying to cast the string HELLO to an integer, this doesn't work of course.
DO ON ERROR, RETRY
This will repeat the block if there's an error and setting RETRY to true. If you don't LEAVE in the RETRY-block you will have a loop.
DO ON ERROR UNDO, RETRY:
IF RETRY THEN DO:
DISPLAY "RETRY".
/* Do some cleanup or what else */
LEAVE.
END.
i = INTEGER("HELLO").
END.
DO ON ERROR, THROW
A perhaps more modern approach when THROW - CATCH is used. Note that this also supresses the error from appearing (a bit like NO-ERROR).
DEFINE VARIABLE i AS INTEGER NO-UNDO.
DO ON ERROR UNDO, THROW:
i = INTEGER("HELLO").
END.
CATCH error AS Progress.Lang.Error :
MESSAGE "We had an error".
END CATCH.
DO:
The program will just halt on error
DEFINE VARIABLE i AS INTEGER NO-UNDO.
DO:
i = INTEGER("HELLO").
END.
The ON ERROR statement gives you control on what happens when the block fails. If you are using ROUTINE-LEVEL error handling for example, errors at the block level are not caught by default, so you can
DO ON ERROR UNDO,THROW:
END.
This will make sure the error is trapped. If you are using BLOCK-LEVEL error handling then this would be trapped by default.
This is just an example, and there are many things you can use ON ERROR for. Have a look at this documentation: https://help.consultingwerkcloud.com/openedge/117/rfi1424919692411.html

What does "rerun in upstream in pipeline"?

I am defining a pipeline in data factory, I had some errors that I correct.
The first activity is calling an usql script to do some aggregation, I changed the script plenty of time but the error is still:
[{"errorId":"E_CSC_USER_SYNTAXERROR","severity":"Error","component":"CSC","source":"USER","message":"syntax
error. Final statement did not end with a semicolon","details":"at
token 'usql', line 4\r\nnear the ###:\r\n**************\r\nCLARE
#lineitemsfile string =
\"/datalakerepo/input/2016/01/01lineitems.txt\";\nDECLARE #ordersfile
string = \"/datalakerepo/input/2016/01/01orders.txt\";\nsales.usql ###
\n","description":"Invalid syntax found in the
script.","resolution":"Correct the script syntax, using expected
token(s) as a
guide.","helpLink":"","filePath":"","lineNumber":4,"startOffset":228,"endOffset":232}].
seem like not all usql script is read from the data factory, so I though that may be the "rerun in upstream in pipeline" have something to do with this, like clear cache from previous script.
Anyone knows what "rerun in upstream in pipeline" does?
Many thanks!
"Rerun with upstream in pipeline" basically means "recalculate with all dependencies". For example, if one has pipeline1 -> dataset1 -> pipeline2 and tries to rerun pipeline2 with dependecies, then pipeline1 and pipeline2 will be both executed. I believe it works same with several chained activities within single pipeline.

Paypal sandbox negative testing not working

I have set up negative testing for an account then set the error code desired as the Transaction Amount Field for example 106.06 to invoke error code 10606 "Buyer cannot pay” no errors are returned the order is processed.
If I try another error code 10539 “This transaction cannot be processed”. An error is return and the order is not processed.
I am using the The US site error codes: http://www.paypalobjects.com/en_US/ebook/PP_APIReference/Appx-ErrorCodes_and_Messages.html and we are in Australia are these the correct error codes?
Any ideas what is causing this? Is this the correct way to use Negative Testing in the sandbox?
Thanks
I know this is late but I stumbled across the answer for me.
You didn't specify the API Name you are working with DoExpressCheckoutPayment and according to Paypal's Negative Testing Docs we are supposed to use an AMT field and
To trigger an error condition on an amount-related field, specify a error code value as a number with two digits to the right of the decimal point. For example, specify a value of 107.55 to trigger the 10755 error.
I found their information to be completely false! What I finally got working was to use PAYMENTREQUEST_0_AMT and NOT use a decimal.
So here is what I came up with
USER={yourUID}&
PWD={yourPSWD}&
SIGNATURE={yourSig}&
TOKEN={yourToken}&
METHOD=DoExpressCheckoutPayment&
VERSION=119&
PAYMENTREQUEST_0_AMT=10486
Edit:
I later found a better option specifically for the Payment Method Refused (10486) that I mentioned above. Take a look: https://developer.paypal.com/docs/classic/express-checkout/ht_ec_fundingfailure10486/#testing-saleorauth

Does "insert" in SQLite return SQLITE_OK or SQLITE_DONE?

What does statement "insert" in SQLite return in case of success?
I always believed that it should be SQLITE_DONE, but recently in my logs I found out the following string:
sqlite3_step error: 'not an error'
And here is the code that logs the mentioned string:
prepareStatement(addTranslationStmt2, "INSERT INTO translations(lang1_wordid, lang2_wordid) VALUES(?, ?)");
if (!addTranslationStmt2) return -2;
sqlite3_bind_int(addTranslationStmt2, 1, word_id);
sqlite3_bind_int(addTranslationStmt2, 2, translation_id);
if(sqlite3_step(addTranslationStmt2) != SQLITE_DONE)
{
NSLog(#"sqlite3_step error: '%s'", sqlite3_errmsg(database));
sqlite3_reset(addTranslationStmt2);
return -1;
}
sqlite3_reset(addTranslationStmt2);
I am wondering, why does it work in most cases.
Should I change SQLITE_DONE in my code to SQLITE_OK?
Thanks.
SQLITE_DONE
http://www.sqlite.org/c3ref/step.html
You could also try printing out the error code to find out what the problem is.
In cases like these, I like to look at code samples. Here are some good ones:
http://sqlite.phxsoftware.com/forums/p/76/6659.aspx
The SQLite Result Codes Reference lists SQLITE_OK as indicating a successful result. It is also the first error code, having an error code of 0, making it the canonical result (i.e. the result I would expect on a successful operation).
You should put a breakpoint or print statement in your code to find out if it really is returning zero, and check your data to make sure you're getting the result you expect. If that all checks out, I would change your condition to check for SQLITE_OK.
The details of the behavior of the sqlite3_step() interface depend on whether the statement was prepared using the newer "v2" interface sqlite3_prepare_v2() and sqlite3_prepare16_v2() or the older legacy interface sqlite3_prepare() and sqlite3_prepare16().
In the legacy interface, the return value will be either SQLITE_BUSY, SQLITE_DONE, SQLITE_ROW, SQLITE_ERROR, or SQLITE_MISUSE. With the "v2" interface, any of the other result codes or extended result codes might be returned as well.
Switching from "Debug" configuration to "Release" resolved the issue for me.

Resources