search

enkessler / cuke_modeler

A gem to model a Cucumber test suite.
MIT License
22 stars 7 forks source link

Fix a few issues creating examples from scratch #1

Closed Donavan closed 8 years ago

Donavan commented 8 years ago

This PR corrects a few minor issues I encountered when creating examples from scratch.

  1. When handing a hash to add_row, it was calling strip! on a frozen string.
  2. When given non string values it would blow up.
  3. When given a hash that used symbols instead of strings for keys it would blow up calling ljust.

There's one non-bugfix change included here on the hash path. When handed a hash, use it's keys to populate the parameters array if that array is currently empty.

coveralls commented 8 years ago

Coverage Status

Coverage increased (+0.002%) to 99.534% when pulling 553b53df1fd1c859b3750070bef33c87e9cb4cbf on Donavan:donavan_fixes into 30a0592b549cc66804a2a992faf89b78e24afed8 on enkessler:master.

enkessler commented 8 years ago

While it is reasonable to use the hash's keys as the implicit parameter list when adding a row of values without having any parameters already set, there are no implicit parameters to be had when adding a row using an array. For the sake of having consistent behavior for both adding rows by Array and adding them by Hash, I'd rather raise an exception in both cases rather than have one of them silently be helpful while the other can do nothing but explode.

Given that the only way to have an empty parameter list in the first place is to be intentionally manipulating the state of the Example object, it seems like a not unreasonable demand on the library's part that the user also intentionally set the parameters as well.

enkessler commented 8 years ago

Regarding using non-string keys/values in the input arrays/hashes: sure, that's an easy enough thing to handle by 'stringifying' the input before processing it. However, it is possible to end up with a mix of strings and symbols as keys if the Example was parsed from source text (resulting in string keys for the initial rows) and then had rows added manually with hashes that used symbols for keys (any rows that were added manually would retain their symbol keys).

Again, for the sake of consistency, I'd prefer that all hash keys are the same kind of object and keeping them all strings will avoid changing existing behavior (in the non-exploding cases, that is).

TLDR: use whatever you like as input, but output will always be strings.

enkessler commented 8 years ago

Merged.