finos
Character set used for string generation should be an optional command line argument
Feature Request
After #1174 the character set used for string generation was changed to basic latin characters - specifically characters in the range \u0020 to \u007E.
Following on from #1075 and #294 this functionality may not always be desired. It should be possible to specify as a command line argument the set of characters used.
Acceptance Criteria:
- [ ] By default strings should be generated from the set of basic latin characters including basic punctuation such as £.
- [ ] additional generation modes (such as?) should also be supported, including the set of all valid unicode characters (excluding special characters such as back space or the bell character)
Ignored test removed from ContainingRegex-SpecialChars.feature:
Feature: Whilst including non-latin characters, user can specify that contains a specified regex
Background: Given the generation strategy is full And there is a field foo And foo has type "string"
Scenario: Running a 'containingRegex' request that includes special characters (non roman character maps: Hiragana) should be successful Given foo is containing regex /[あ-げ]{1}/ And foo is of length 1 Then the following data should be generated: | foo | | null | | "あ" | | "ぃ" | | "い" | | "ぅ" | | "う" | | "ぇ" | | "え" | | "ぉ" | | "お" | | "か" | | "が" | | "き" | | "ぎ" | | "く" | | "ぐ" | | "け" | | "げ" |
Scenario: Running a 'containingRegex' request that includes special characters (emoji) only should be successful Given foo is containing regex /[😁-😘]{1}/ And foo is of length 1 Then the following data should be generated: | foo | | null | | "😁" | | "😂" | | "😃" | | "😄" | | "😅" | | "😆" | | "😉" | | "😊" | | "😋" | | "😌" | | "😍" | | "😏" | | "😒" | | "😓" | | "😔" | | "😖" | | "😘" |
Removed from MatchingRegex-SpecialChars:
Scenario: Running a 'matchingRegex' request that includes special characters (non roman character maps: Hiragana) should be successful Given foo is matching regex /[あ-げ]{1}/ Then the following data should be generated: | foo | | null | | "あ" | | "ぃ" | | "い" | | "ぅ" | | "う" | | "ぇ" | | "え" | | "ぉ" | | "お" | | "か" | | "が" | | "き" | | "ぎ" | | "く" | | "ぐ" | | "け" | | "げ" |
The following tests were removed from InSet-SpecialChars.feature:
Feature: Whilst including non-latin characters, User can specify that a field value belongs to a set of predetermined options.
Background: Given the generation strategy is full
inSet alone
Scenario: Running an 'inSet' request that includes strings with special characters (standard) should be successful Given there is a field foo And foo is in set: | "!£$%^&()" | | "{}:@~;'#<>?" | Then the following data should be generated: | foo | | null | | "!£$%^&()" | | "{}:@~;'#<>?" |
Scenario: Running an 'inSet' request that includes strings with special characters (white spaces) should be successful Given there is a field foo And foo is in set: | "] [] [] [] [" | | "] [] [] [" | Then the following data should be generated: | foo | | null | | "] [] [] [] [" | | "] [] [] [" |
Scenario: Running an 'inSet' request that includes strings with special characters (unicode symbols) should be successful Given there is a field foo And foo is in set: | "†ŠŒŽ™¼Dž©" | | "®…¶Σ֎" | Then the following data should be generated: | foo | | null | | "†ŠŒŽ™¼Dž©" | | "®…¶Σ֎" |
Scenario: Running an 'inSet' request that includes strings with special characters (emoji) should be successful Given there is a field foo And foo is in set: | "🚫⌛⚡🐢" | | "👟💪😈🔬" | Then the following data should be generated: | foo | | null | | "🚫⌛⚡🐢" | | "👟💪😈🔬" |
Scenario: Running an 'inSet' request that includes strings with special characters (non roman character maps) should be successful Given there is a field foo And foo is in set: | "Ω" | | "ڦ" | | "আ" | | "⾉" | | "㑹" | | "㾹" | Then the following data should be generated: | foo | | null | | "Ω" | | "ڦ" | | "আ" | | "⾉" | | "㑹" | | "㾹" |
Scenario: Running an 'inSet' request that includes roman numeric strings that include numbers with Preceding zeros should be successful Given there is a field foo And foo is in set: | "£1.00" | | "€5,99" | | "¥10,000" | Then the following data should be generated: | foo | | null | | "£1.00" | | "€5,99" | | "¥10,000" |
The following tests were removed from the EqualTo-SpecialChars.feature file:
eature: Whilst including non-latin characters, user can specify that a value is equalTo a required value
Background: Given the generation strategy is full
alone
Scenario: Running an 'equalTo' request that includes strings with special characters (standard) should be successful Given there is a field foo And foo is equal to ".,;:/()-+£$%€!?=&#@<>[]{}^" Then the following data should be generated: | foo | | null | | ".,;:/()-+£$%€!?=&#@<>[]{}^" |
Scenario: Running an 'equalTo' request that includes strings with special characters (like white space strings) should be successful Given there is a field foo And foo is equal to "] [] [] [] [] [] [] [" Then the following data should be generated: | foo | | null | | "] [] [] [] [] [] [] [" |
Scenario: Running an 'equalTo' request that includes strings with special characters (unicode symbols) should be successful Given there is a field foo And foo is equal to "†ŠŒŽ™¼Dž©®…¶Σ֎" Then the following data should be generated: | foo | | null | | "†ŠŒŽ™¼Dž©®…¶Σ֎" |
Scenario: Running an 'equalTo' request that includes strings with special characters (emoji) should be successful Given there is a field foo And foo is equal to "☺☹☻😀😁😂😃😄😅😆😇😈😉😊😋😌🚩🚪🚫🚬🚭🚮🚯🚰" Then the following data should be generated: | foo | | null | | "☺☹☻😀😁😂😃😄😅😆😇😈😉😊😋😌🚩🚪🚫🚬🚭🚮🚯🚰" |
Scenario: Running an 'equalTo' request that includes strings with special characters (non roman character maps: Chinese / Arabic / Russian) should be successful Given there is a field foo And foo is equal to "传/傳象形字ФХѰѾЦИتشرقصف" Then the following data should be generated: | foo | | null | | "传/傳象形字ФХѰѾЦИتشرقصف" |
Scenario: Running an 'equalTo' request that includes strings with special characters (non roman character maps: Chinese / Arabic / Russian) should be successful Given there is a field foo And foo is equal to "בְּרֵאשִׁית, בָּרָא אֱלֹהִים, אֵת הַשָּׁמַיִם, וְאֵת הָאָרֶץ" Then the following data should be generated: | foo | | null | | "בְּרֵאשִׁית, בָּרָא אֱלֹהִים, אֵת הַשָּׁמַיִם, וְאֵת הָאָרֶץ" |
Scenario: Running an 'equalTo' request that includes strings with special characters (standard) alongside roman alphanumeric characters should be successful Given there is a field foo And foo is equal to "abcdefghijk.,;:/()-+£$%€!?=&#@<>[]{}^" Then the following data should be generated: | foo | | null | | "abcdefghijk.,;:/()-+£$%€!?=&#@<>[]{}^" |
Scenario: Running an 'equalTo' request that includes strings with special characters (white spaces) alongside roman alphanumeric characters should be successful Given there is a field foo And foo is equal to "abcdefghijk] [] [] [] [] [] [] [" Then the following data should be generated: | foo | | null | | "abcdefghijk] [] [] [] [] [] [] [" |
Scenario: Running an 'equalTo' request that includes strings with special characters (unicode symbols) alongside roman alphanumeric characters should be successful Given there is a field foo And foo is equal to "abcdefghijk†ŠŒŽ™¼Dž©®…¶Σ֎" Then the following data should be generated: | foo | | null | | "abcdefghijk†ŠŒŽ™¼Dž©®…¶Σ֎" |
Scenario: Running an 'equalTo' request that includes strings with special characters (emoji) alongside roman alphanumeric characters should be successful Given there is a field foo And foo is equal to "abcdefghijk☺☹☻😀😁😂😃😄😅😆😇😈😉😊😋😌🚩🚪🚫🚬🚭🚮🚯🚰" Then the following data should be generated: | foo | | null | | "abcdefghijk☺☹☻😀😁😂😃😄😅😆😇😈😉😊😋😌🚩🚪🚫🚬🚭🚮🚯🚰" |
Scenario: Running an 'equalTo' request that includes strings with special characters (non roman character maps: Chinese / Arabic / Russian) alongside roman alphanumeric characters should be successful Given there is a field foo And foo is equal to "abcdefghijk传/傳象形字ФХѰѾЦИتشرقصف" Then the following data should be generated: | foo | | null | | "abcdefghijk传/傳象形字ФХѰѾЦИتشرقصف" |
Scenario: Running an 'equalTo' request that includes roman numeric strings that include numbers in a currency style should be successful Given there is a field foo And foo is equal to "£1.00" Then the following data should be generated: | foo | | null | | "£1.00" |