5

I want to update a custom user field in QC using the Label of field instead of the name

At the moment we are doing it this way

Set currentRun = QCUtil.CurrentRun
currentRun.Field("RN_USER_03") = 1
currentRun.Post

But I would like to do it this way

Set currentRun = QCUtil.CurrentRun
currentRun.Field("Data Rows Passed") = 4
currentRun.Post

But I can't find the method to do it with. Any Ideas?

Motti
  • 110,860
  • 49
  • 189
  • 262
Jonas Söderström
  • 4,856
  • 2
  • 36
  • 45
  • 1
    Why would you want to do that ? Why can't you use the name as you do today ? – Alex Shnayder Jun 25 '10 at 21:29
  • Hi Alex. Good question. Reason is that we use many custom fields and it will be difficult for testers/developers to implement and maintain the tests with names like "RN_USER_03", it will be very easy to get confused and make misstakes, and very hard to read the code. The labels will not change very often and thats why we want to use labels instead. – Jonas Söderström Jul 05 '10 at 19:49
  • 1
    Couldn't you just as easily assign the field name to a constant with a meaningful name? `const DATA_ROWS_PASSED = "RN_USER_03" currentRun.Field(DATA_ROWS_PASSED) = 4` – Tom E Jul 06 '10 at 13:17
  • Hi Tom. That might be a good idea incase it's not possible to access via lable. I'll check this with the team. Thanks – Jonas Söderström Jul 15 '10 at 14:37

2 Answers2

1

Look at this:

Dim gFieldLabelToNameDICT: Set gFieldLabelToNameDICT = CreateObject("Scripting.Dictionary")
gFieldLabelToNameDICT.CompareMode = vbTextCompare

Function GetNameOfLabel (strFieldLabel)
    ' If it doesn't exist yet in fieldLabelToName dict -> search it using TDC and add it to the list to improve performance
    If Not gFieldLabelToNameDICT.Exists(strFieldLabel) Then
        Dim testSetFields As List

        Dim testSetFields: Set testSetFields = QCUtil.QCConnection.Customization.Fields.Fields("RUN")
        For Each aField in testSetFields
            If aField.UserLabel = strFieldLabel Then
                gFieldLabelToNameDICT.Item(strFieldLabel) = aField.ColumnName
            End If
        Next aField
    End If

    GetNameOfLabel = gFieldLabelToNameDICT.Item(strFieldLabel)
End Function

Maybe you shall want to add some more error handling, such us considering the case that the label is not found.

1

Implying all labels are unique (which I doubt..):

You could create a function which accepts a label, searches in QC's tables that define customized fields for the correct field definition, and returns the field name. Then use the function's result value as the indexed property's index.

Suppose that function would be called "GetNameOfLabel", then the Caller's code would look like:

Set currentRun = QCUtil.CurrentRun 
currentRun.Field(GetNameOfLabel ("Data Rows Passed")) = 1 
currentRun.Post 

Of course, the function would not really be trivial, but easy enough after some digging in the QC data model and finding an efficient way to fetch the name from the DB via SQL.

Or, the function could look up the name in an array, or a dictionary, then you would have to maintain that dictionary, but you would not have to go to the database for each lookup.

Disadventages:

  • Scripts with the wrong label might be harder to be debug
  • If labels are not unique, it might be real "fun" to debug

If looking up on the DB:

  • All scripts slow down if you don't cache, or pre-load, SQL query results for those lookups;
  • complexity, as you have to do the right SQL query, and you depend on QC's data model in a quite peculiar way (usually a horror when you're upgrading)

If looking up in an array, or dictionary:

  • You either must maintain its initialization (bet other admin guys adding a cust field will forget that easily), or must "load" it from QC's table (which is a bit like the SQL solution above, and has the same downsides).

I'd go with the array/dictionary-initialized-from-db-idea. Or, if you can live with the constant idea already presented, that one is a good bet. Considering that there is no session-independent scope in QCs customizing scripts, the SQL access idea might really kill performance because it would have to be executed for every new user session. Which is why I, too, +1'd the constant idea.

TheBlastOne
  • 4,291
  • 3
  • 38
  • 72
  • 1
    @Jonas: Please, occasionally let us know which of the options you actually used, and what your experiences with them were. – TheBlastOne Nov 25 '10 at 08:53
  • 1
    Better late reply than never :) We ended up wrapping everything in functions. So "currentRun.Field("RN_USER_03") = 1" was wrapped in something like, "update_data_rows_passed(rows_passed)". All the functions were placed in our core libraries and was always included in all tests. So most test engineers were only exposed to the functions and only the core team updated the functions, and once we wrote them they hardly ever changed. It was an easy way to solve our problem and it worked great. Thanks for the interest. – Jonas Söderström Oct 06 '11 at 07:05