Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for triggering/transforming parameterTypes in data table #2160

Closed
k02pradeep opened this issue Jan 29, 2024 · 2 comments
Closed

Support for triggering/transforming parameterTypes in data table #2160

k02pradeep opened this issue Jan 29, 2024 · 2 comments

Comments

@k02pradeep
Copy link

🤔 What's the problem you're trying to solve?

ParameterType works well when using parameter type in the step definitions.
When the step has data table argument, then based on the column Id ( row[0] entries) , data should be transformed based on the parameterTyep( columnId in this case).

✨ What's your proposed solution?

DataTable model should support new method to return the transformed data.

⛏ Have you considered any alternatives or workarounds?

Utilities can be created used for this. but it would require duplicating the logic code for parameterType.
This would again increase the complexity within the step definition.

📚 Any additional context?

DataTable constructor can take second argument for expression and add new method called transformed() which would do return return the transformed data after applying parameterType transformations.


This text was originally generated from a template, then edited by hand. You can modify the template here.

@davidjgoss davidjgoss transferred this issue from cucumber/cucumber-js Jan 30, 2024
@davidjgoss
Copy link
Contributor

Other maintainers might feel differently, but I don’t think is something we would add to Cucumber. You an always extend/wrap DataTable to do what you need though.

@mpkorstanje
Copy link
Contributor

There are many ways a data table could be mapped to an object , but using parameter types would be a conceptual mismatch.

Anyway, I think it would be more useful to start a feature request from a concrete real world example. I.e. the problem you're trying to solve, not the solution you imagine.

@mpkorstanje mpkorstanje closed this as not planned Won't fix, can't repro, duplicate, stale Feb 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Done
Development

No branches or pull requests

3 participants