Execute SQL Script - Better to use a sql file or raw sql script

[Nick Shaw]

Hi guys,

I'm pretty new to robot and did a search here without turning up something similar, so apologies for the dumb question!

However, I was wondering if it is preferable with the Execute SQL Script keyword to use raw sql script or use a variable which contains the location of a sql script?  In this case I will be using it for test case setup and teardown.  These are going to be individual and not candidates for re-use across test cases.

Example 1:

[Setup]     Execute Sql Script      DELETE FROM [dbo].[nick] where Name='Test'; INSERT INTO [dbo].[nick] (Name) VALUES ('Test')

Example 2:

[Setup]     Execute Sql Script      ${NICK_TEST_SETUP_SCRIPT}

As mentioned this is likely to be on a test case basis rather than being re-usable.  To me having a separate file containing the query is 'cleaner' but I don't particularly want to have a folder full of extremely basic SQL inserts etc as it seems like a waste of space.  I'd be most concerned with the performance viewpoint, if it takes a few seconds to locate the file etc, then x100 this obviously adds up.

Thanks for any guidance you can provide.

Regards,

Nick

[Ben Fariello]

If they're simple sql queries, is there a reason you don't want to have an "Execute SQL Query" keyword that takes the query as a parameter? One keyword to rule them all. And you can always Document the case to say What you're testing, of course.

[Tatu Aalto]

Ugh

This is a difficult question which does not have a single correct or right answer. The best answer what I can give: It depends.

If I would need to decide on this kind of matter, I would think who is the audience. If the audience contains only people who are fluent on SQL and if these SQL statements are only test case specific, then, perhaps, I would write plain SQL statements to the test setup. Also the SQL should not bee too complex, audience should understand the SQL in (very) short time. If the SQL is long and/or complex, the test setup takes the attention away from what is being actually tested in the test case part.

If the audience contains people that are not fluent on SQL, then I would hide the complex SQL to a variable or in a keyword. The variable or the keyword name should describe what is the important part in the setup. I usually try to keep the name as short as possible and only mention the most important part. If course, at least for me, this is not always possible because there might be too many important things to mention, then I usually write: suite setup for xxx.

But where to put the test (suite) specific keywords and variables. I tend to create a resource, file in same place where the suite is and place all the test suite specific stuff in that resource file. I do this because I want to keep the actual test suites as short and clean as possible. You could also place the test specific keywords and variables to the test suite file.

I think the performance should not be an issue, last time I did count, in our company, we did have about two hundred resource files and libraries in use. We have +1000 keywords in those files. I would assume that during normal test execution, almost all are imported and actually about 50% of the files are used and I have not noticed a performance issue (in this area).

But to get a better answer, write the same test in few different ways and ask opinion from your audience. And as a further reading, I think all the things in the "How to write good test cases"[1] are valid, but may not be suitable in your situation.

-Tatu
Send from my mobile
[1] https://code.google.com/p/robotframework/wiki/HowToWriteGoodTestCases

--
You received this message because you are subscribed to the Google Groups "robotframework-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to robotframework-u...@googlegroups.com.
To post to this group, send email to robotframe...@googlegroups.com.
Visit this group at http://groups.google.com/group/robotframework-users.
For more options, visit https://groups.google.com/d/optout.

[Nick Shaw]

Hi Ben,

there's no specific reason, that is actually the approach I'm currently taking.  As mentioned I'm new to robot and wasn't sure on what 'best practice' was.  I don't want people coming to my tests and being confused as they're written in a very different way from normal.

A problem I see in using variables, especially for very small scripts is that it removes readability, I now need to find that variable to know exactly what is being executed.  This obviously should be a very simple task but little things add up.

Thanks for your reply!

[Nick Shaw]

Hi Tatu,

thank you very much for your detailed and well thought out reply.  It is certainly a tricky thing to answer but I think you're spot on with attempting some different ways and seeing how well or how badly my attempts are received by my peers.

Thank you also for the test case resource, I could certainly do with a refresher!

Regards,

Nick

To unsubscribe from this group and stop receiving emails from it, send an email to robotframework-users+unsub...@googlegroups.com.