ISSUE-675 # Url encode dynamic values using URLENCODED token

[imBharatMalviya]

URL encode dynamic values using the URLENCODED token

Fixed Which Issue?

• Which issue or ticket was(will be) fixed by this PR? (capture the issue link here)
  • How to encode some data, which we need to use in consecutive requests #675

PR Branch
issue-675-urlencoded-token

Motivation and Context

A step could not reuse a value produced by an earlier step in its url when that
value contains special characters. e.g. an id like #37:29 has to travel over
the wire as %2337%3A29, and the DSL had no way of encoding it, so such flows
(POST then GET/PUT/DELETE by the generated id) were not automatable.

This PR introduces the URLENCODED: value token, which encodes the resolved
value with URLEncoder.encode(value, "UTF-8"), i.e. exactly the behaviour asked
for in the issue.

"url": "/questions/${URLENCODED:$.POST_QUESTIONS.response.body.id}"

The id #37:29 of the earlier step now reaches the server as
/questions/%2337%3A29.

It resolves in the url, request and assertions sections, and supports:

Usage	Resolves to
${URLENCODED:$.step_name.response.body.id}	encoded json path of an earlier step
${URLENCODED:#37:29}	encoded static value
${URLENCODED:LOCAL.DATE.TODAY:yyyy/MM/dd}	encoded nested known token
${URLENCODED:web.application.endpoint.context}	encoded target env property

Changed classes:

• ZeroCodeValueTokens - new URL_ENCODED token, registered as a known token
• TokenUtils - new urlEncoded(...), encodes static values and nested tokens
• ZeroCodeAssertionsProcessorImpl - encodes the json paths of earlier steps
  after they are resolved against the scenario state, and target env properties

Existing token behaviour is untouched. An absent json path leaves the token as
it is, which is how the plain json paths already behave.

Checklist:

• 1. New Unit tests were added

  • 1.1 Covered in existing Unit tests

• 2. Integration tests were added

  • 2.1 Covered in existing Integration tests

• 3. Test names are meaningful

• 3.1 Feature manually tested and outcome is successful

• 4. PR doesn't break any of the earlier features for end users

  • 4.1 WARNING! This might break one or more earlier earlier features, hence left a comment tagging all reviewrs

• 5. PR doesn't break the HTML report features directly

  • 5.1 Yes! I've manually run it locally and seen the HTML reports are generated perfectly fine
  • 5.2 Yes! I've opened the generated HTML reports from the /target folder and they look fine

• 6. PR doesn't break any HTML report features indirectly

  • 6.1 I have not added or amended any dependencies in this PR
  • 6.2 I have double checked, the new dependency added or removed has not affected the report generation indirectly
  • 6.3 Yes! I've seen the Sample report screenshots here, and HTML report of the current PR looks simillar.

• 7. Branch build passed in CI

• 8. No 'package.*' in the imports

• 9. Relevant DOcumentation page added or updated with clear instructions and examples for the end user

  • 9.1 Not applicable. This was only a code refactor change, no functional or behaviourial changes were introduced

• 10. Http test added to http-testing-examples module(if applicable) ?

  • 10.1 Not applicable. The changes did not affect HTTP automation flow

• 11. Kafka test added to kafka-testing-examples module(if applicable) ?

  • 11.1 Not applicable. The changes did not affect Kafka automation flow

Tests added

• Unit - 6 cases in TokenUtilsTest, 6 cases in ZeroCodeAssertionsProcessorImplTest
• Integration - integrationtests/urlencoded/UrlEncodedTokenTest, a two step
  scenario passing an id with special chars from one step to the next
• Http example - HelloWorldUrlEncodedTest does a real POST then GET against
  the local mock server and is added to the surefire list so CI runs it

Local test run

• mvn -pl core clean test - all unit and integration tests pass, except the
  ones that need the CI docker containers, which are not reachable locally.
• mvn -pl http-testing-examples test - 10 tests, all green.