String parameter beginning with numbers are wrongly interpreted as numbers

[anthony-legay]

Describe the bug
Say we have spec like this one:
* Get product with id "81423165-ad04-4c7b-9f85-75d1a8aa1b0d"

Since #186, which now uses Number.parseFloat directly instead of Number constructor in the PrimitiveParser, strings like the UUID above or even parameters which could be product IDs like "012345" are now successfully converted to Number (instead of NaN), dropping useful characters in the process (excess hex letters for the UUID, leading zeroes for the product ID)...which makes it pretty much unusable right now.

To Reproduce
Steps to reproduce the behavior:
Just use a UUID or a static parameter beginning with one or more 0

Expected behavior
A clear and concise description of what you expected to happen.
With a spec like:

* Get product with id "81423165-ad04-4c7b-9f85-75d1a8aa1b0d"

and an implementation like:

@Step("Get product with id <productId>")
public async getCart(productId: string) {
  assert.equal(productId, "81423165-ad04-4c7b-9f85-75d1a8aa1b0d") // currently 81423165
}

Desktop (please complete the following information):

• OS: macOS Sonoma 14.7
• Gauge and plugin version 3.0.2 (latest)
• Node version: 20.17.0
• Npm version: 10.8.2

[zabil]

Re-opening to cover the following case #191 (comment)

[anthony-legay]

We also need to be careful with a simple startsWith('0') (I already thought about this one actually 😅) as it would also not cover values like "0.42" (like a rate or something) 🤯

[zabil]

@anthony-legay

I believe this is covered in the current code. I've tried the following.

* Check number starting with 0 for example "012" is correct
* Check number starting with 0 and decimal "0.12" is correct

  @Step("Check number starting with zero for example <value> is correct")
  async numberStartingWithZero(value: string) {
    assert.strictEqual(typeof value, "string");
    assert.strictEqual(value, "012");
  }

  @Step("Check number starting with zero and decimal <value> is correct")
  async decimal(value: string) {
    assert.strictEqual(value, "0.12");
  }

Have you tried running it?

[hazzik]

In 0.3.5 I'm getting "1" passed down as a number instead of string.

This is my step.

Write "1" into "Phone number"

And this is my step implementation:

@Step("Write <value> into <name>")
public static async writeInto(value: string, name: string) { /*...*/ }

To clarify: this step is a part of test that will check that the field shows "invalid phone number" warning.

Is it possible to get the correct type from the implementation method definition instead of blindly trying to convert to number if it fits?

[ckcr4lyf]

Just my $0.02: Upgrading from gauge 0.1 -> 0.3, I was quite surprised by the whole "automatic primitive type parsing", since previously it was all a string.

IMO these odd edge cases are a good reason to go back to the default of just assuming everything is a string. As I write step implementations, I can have custom logic since I know what format I expect the string to be in, and parse it if required for that step.

(For some context: I had a lot of steps which accepted "numeric" arguments, but were used as strings, and now it was all failing).

[mizuochi-hikaru]

Sorry to comment out of the blue.
I agree with @ckcr4lyf.

I use Playwright with Gauge, and the steps I have implemented are as follows:

@Step("fill <value> to the input element")
public async fillInput(value: string) {
  const locator = getCurrentLocator();
  await locator.fill(value);
}

This step is used like this:

* In the e-mail address input field:
* fill "[email protected]" to the input element
* In the phone number input field:
* fill "0123456789" to the input element

Method locator.fill takes a string as its argument.
If a string is converted to a number, it must be converted to a string each time. Even though a string is specified in the argument of step.

Because of this automatic conversion, I still have not been able to update my version from 0.1.1 to 0.3.x.

[zabil]

In retrospect, the decision to convert based on the parameter is not ideal. The ideal approach instead is to determine the step parameter’s type and attempt a conversion to the target type.

However, type information is unavailable at runtime when the step is loaded. I’ll investigate further, but for now, I agree about reverting to the original behaviour of assuming everything to be a string.