Skip to content

Import multi-persona conformance toolkit from sandbox repo - #1

Open
nitparihar wants to merge 2 commits into
devfrom
feature/multi-persona-conformance
Open

Import multi-persona conformance toolkit from sandbox repo#1
nitparihar wants to merge 2 commits into
devfrom
feature/multi-persona-conformance

Conversation

@nitparihar

Copy link
Copy Markdown

Moves the WFM Supplier and Application Supplier conformance test toolkit (runner, data generator, Postman/Newman collections, test cases) from margo/sandbox conformance/ into this dedicated repo, flattened to the repo root.

Source: margo/sandbox @ 7bbf36b (branch feature/multi-persona-conformance)

Moves the WFM Supplier and Application Supplier conformance test
toolkit (runner, data generator, Postman/Newman collections, test
cases) from margo/sandbox conformance/ into this dedicated repo,
flattened to the repo root.

Source: margo/sandbox @ 7bbf36b (branch feature/multi-persona-conformance)

@spulkit138 spulkit138 left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As a general observation, code comments are missing, which makes the code unmaintainable in long run. Would advise to add code comments wherever necessary.
As a general rule, adding code comments for function headers, describing what they do & any pointers to keep in mind while using them; & adding comments where workflow is complex should suffice.

@spulkit138 spulkit138 left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another observation, unit tests are not written. Writing unit test cases can help determine behaviour and reduce the amount of surprises or redundant testing-fixing effort cycle towards the end. It helps in maintaining codebase, and if someone changes some logic, unit test cases help in validating whether code changes are conformant to business logic or not.
Would advice to add unit test cases wherever required.


switch v := value.(type) {

case []interface{}:

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

use of any instead of interface{} is more readable and compact.
It is being used almost everywhere, hence should be changed at those places, not commenting on every occurence.

Suggested change
case []interface{}:
case []any:

Comment on lines +509 to +519
if !refMap[actual] {

fail(
report,
actual,
msg.Fail.Invalid,
)

return
}
}

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is a concept of "early exit" in Go, which can usually be implemented in any language but considered idiomatic in Go. It makes code readable & maintainable.
Following this approach also makes your code less "pecking to the right".
Please consider using this approach in Go code.

This is seen at multiple places, if you deem it right, should change at those places as well.

Suggested change
if !refMap[actual] {
fail(
report,
actual,
msg.Fail.Invalid,
)
return
}
}
// This makes the loop to stop checking and continue to next
if refMap[actual] {
continue
}
fail(
report,
actual,
msg.Fail.Invalid,
)
return
}

Comment on lines +523 to +536
actual := formatActual(
item,
)

if !refMap[actual] {

fail(
report,
actual,
msg.Fail.Invalid,
)

return
}

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This code chunk is seen multiple times, can a function be made with approapriate parameters which replaces this at multiple places? Code redundancy should be avoided. Please check for code redundancy at all other places as well.


if strings.HasPrefix(
location,
"http://",

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

commonly used strings should be made a constant & then used elsewhere.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants