Sửa lỗi input string was not in a correct format năm 2024

Expected behavior for me would be: mark new steps in .feature file as they are not defined (binding method does not exist), and then user have to generate new binding methods without issues with forwarded parameters in run time.

Steps to Reproduce

1. Generate default specflow .feature file (steps are marked with purple font - no binding methods defined yet)
2. Generate default specflow Steps.cs file from existing .feature file steps (with regex form)
3. After doing ctrl + shift + S (Save All) all steps in .feature file are marked with black font
4. Build project, and run scenario -> there should no exist failing message for "Input string was not in a correct format."
5. Afterwards add 2 new Given steps in .feature file

   - And I have entered "70" into the calculator

   • And I have entered '70' into the calculator
6. Specflow will bind these 2 new steps with existing Method1(int p0) and these new 2 steps will be marked with black font in .feature file
7. Build project, run scenario
8. For steps where parameters are forwarded under " " or ' ', there is message "Input string was not in a correct format."

Note: problem does not manifest if we write all steps because SpecFlow will generate new file with all corresponding binding methods (3 of them).

The text was updated successfully, but these errors were encountered:

If you have the parameters in quotes, you have to adjust the regex, or you will have the quotes in the string that is converted to int.

If i adjust regex of existing binding method with '(.*)' (instead of (.*)) then only And I have entered '70' into the calculator will be bind. First and Third Given steps will be marked with purple text font.

Or i could do something like this:

[Given(@"I have entered ""(.*)"" into the calculator")]
[Given(@"I have entered (.*) into the calculator")]
[Given(@"I have entered '(.*)' into the calculator")]
public void GivenIHaveEnteredIntoTheCalculator(int p0){

I might have question: is possible to do it inside one-same regex?

Anyway, it still seems to me a bit strange: specflow can bind all three given steps when i put (.*) in regex (even with run time error), but when i adjust regex with '(.*)' instead of (.*), then specflow recognizes that there are no binding methods for 2 given steps and after generating them i have everything with expected behaviors. What do you think?

Hi @StefanZivkovic, in theory, it should be possible to capture it in all different ways in one regex. But this would most likely result in a regex which is very hard to read and understand. I'd recommend you to annotate the packages.config`3 method with multiple `packages.config`4 tags like you mentioned before, since it is far more readable. Although, to be sure, I'd replace (.*)` with `packages.config`6 in each regex anyways. This causes SpecFlow to capture only numeric values and all other values are ignored.

Considering your last note: The reason for this behavior is that the (.*) regex pattern captures everything. Some examples for it:

input captured with `(.*)`captured with `packages.config`6 I have entered 1 into the calculator 1 1 I have entered '1' into the calculator '1' [nothing] I have entered "1" into the calculator "1" [nothing]

As you can see, the problem is caused by the (.*) regex capturing the number including surrounding apostrophes. Therefore, SpecFlow will always find a matching step definition. When executing, SpecFlow tries to parse the received string to an int. If SpecFlow tries to parse the string `1 to an int, it will succeed. If it tries to parse either 2 or 3, it will fail since these are not valid int strings. SpecFlow uses .NET's `4 method for this. You can look up valid number formats at the .

I'd strongly recommend you to replace (.*) always with something more concrete, i.e. packages.config`6 in this case, especially if you intend to use numbers without surrounding them with 7 or `8.

Hope this helps you.

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.