crypto-square: tests are implementation specific.

[Insti]

The conclusion reached in Intermediate functions: To test or not to test? was that intermediate functions should not be tested.

The Ruby crypto-square tests are basically all intermediate function tests.

The x-common test data also includes tests for intermediate functions.

The Ruby tests and the x-common test data need to be rewritten to eliminate intermediate function testing.

Edit: to fix test data link

[nickborromeo]

@Insti wanted to help out with this particular issue. I read through all the links and the discussions that you all had however its still not that clear to me what intermediate functions are 😄

[Insti]

@nickborromeo ,

The readme says:

Write a program that, given an English text, outputs the encoded version of that text.

So the "acceptance" tests should be of the form:

assert_equal 'encodedtext', crypto.encode

However the tests that currently exist are full of tests for things like:

assert_equal '123go', crypto.normalize_plaintext
assert_equal 4, crypto.size
assert_equal %w(zomg zomb ies), crypto.plaintext_segments

normalize_plaintext, size, plaintext_segments etc. are the intermediate functions.

Having them in forces you to re-implement the same solution as the initial test writer, but they are not necessarily required to solve the problem which is just to do the required encoding.

[rbasso]

I don't know if it will help; but, after reading this issue, we came to a similar conclusion in exercism/haskell#259.

Because the intermediary tests where most of the test suite, we had to write new tests in exercism/haskell#391:

cases :: [Case]
cases = [ Case { description = "perfect square, all lowercase with space"
               , input       = "a dog"
               , expected    = "ao dg"
               }
        , Case { description = "perfect rectangle, mixed case"
               , input       = "A camel"
               , expected    = "am ce al"
               }
        , Case { description = "incomplete square with punctuation"
               , input       = "Wait, fox!"
               , expected    = "wtx af io"
               }
        , Case { description = "incomplete rectangle with symbols"
               , input       = "cat | cut -d@ -f1 | sort | uniq"
               , expected    = "ctoi adrq tft c1u usn"
               }
]

To keep a smooth progression, we are sequentially testing each of the outputs for the following properties:

• Does the output have the expected non-space characters?
• Does the output have the expected non-space characters in the correct order?
• Does the output have the expected blocks?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[nholden]

I'm wrapping up a couple of pull requests in problem-specifications to improve the canonical data and description. Once those are live, I'll submit a PR in this repo that reflects the changes.