Forum Discussion

dpeterson's avatar
dpeterson
Occasional Contributor
12 years ago

aqString.StrMatches only works with hard-coded strings. Seriously???

The following statement returns a boolean value as stated in the product documentation for aqString.StrMatches:



result = aqString.StrMatches("dog", "The quick brown fox jumps over the lazy dogs");



Value for result is true (as expected).



However:



var pattern = "dog";

var text = "The quick brown fox jumps over the lazy dogs";

result = aqString.StrMatches(pattern, text);



Value for result is an object??????? Specifically (from the locals window):



result (Object)

  ListSeparator     |

  QuoteSymbol    "

  stAll                   3

  stLeading          1

  stTrailing           2





What did I do wrong? I can't believe that this function is designed only to work with hard-coded strings. That would be useless. 



13 Replies

Show More
  • matt_rasband's avatar
    matt_rasband
    New Contributor
    12 years ago
    Things like this are why I stay as far away from the smart bear built ins as possible.  JScript (even this ancient implementation) supports regex, which is probably a better approach to finding strings often anyway, IMO.  Not sure why they wanted to re-invent the wheel with a lot of the stuff.
  • AlexKaras's avatar
    AlexKaras
    Community Hero
    12 years ago
    Hi Matt,



    > [...] why they wanted to re-invent the wheel with a lot of the stuff.

    Personally for me the reason is simple and corresponds to my personal experience:

    -- It is perfectly fine to use specifics of the selected script language but only when you work for the same employer and with the same project; but

    -- If you already have a reasonable test code base and need to create test code using different script languages (e.g. when providing consultancy services) it is more convenient to use TestComplete's built-in functions. This is more convenient just because in this case if you need to port some code to another script language, the only thing that you need to do is to adjust the syntax (add/remove semicolons, replace 'return' with the name of the function, etc.). This can be done really quickly and you don't need to change anything in the test code itself. Whereas if the original test code uses some language peculiarities, you will need to implement this using the means of the language you are porting the code to. This will require time and this time loss may be eliminated by trying to use the built-in functions as much as possible.
  • matt_rasband's avatar
    matt_rasband
    New Contributor
    12 years ago
     Alexei,



    I see where you are coming from and I have no issue with smartbear wanting to have the option for those use cases.  However, for the portion of the population that is an in-house testing department, this can cause major annoyances as their implementations are limited and since they haven't updated the actual language support as they spend time doing this, the language support falls by the wayside as well.



    The issue for me isn't that SB has another implementation, it's the fact that they spend time doing stuff like that when basic modern language support isn't even there (i.e. in JS we have to re-implement basic prototypes such as forEach and hack an inheritance model to work).



    (Sorry for the bold text, the editor won't let me toggle it on Chrome - it's not intended to mean anything.  Oddly, italics will toggle.).