reworked pangram spec#406
Conversation
| unique; | ||
|
|
||
| var Pangram = function(candidate) { | ||
| var msg = candidate || ''; |
There was a problem hiding this comment.
had to add a missing null check
|
|
||
| xit('pangram with non-ascii characters', function() { | ||
| var pangram = new Pangram("Victor jagt zwölf Boxkämpfer quer über den großen Sylter Deich."); | ||
| xit('ignores non-ANSI characters', function() { |
There was a problem hiding this comment.
Trying to bring Unicode to devs attention.
|
@Vankog thanks for taking this on. In general my feeling on these changes is that the tests should be brought in to line with the latest canonical data. Usually the only time we want to vary from that is if there is some JavaScript-specific issue or behavior that ought to be called out. A good example would be So, I think the best thing would be:
Does that make sense to you? |
|
OK, I didn't have the feeling that the canonical tests were taken quite seriously in the tracks. Especially, because the canonicals left some things open to desire. So I took them for inspiration and made sure that they are indeed covered by my new spec. But I also expanded the cases to important edge cases. |
|
@Vankog actually, what I'm saying is: if you feel strongly about the need to add, remove, or change tests, they should first be added, removed, or changed in the canonical specfile, then in each language track. I'm not married to the current set of tests, which don't match the canonical specfile, so I would be in favor of changing them, but the right way to do it is by first getting some community consensus on what the right set of tests is. Does that make sense? In general I feel the right set of tests not only covers all the cases, but helps the developer recognize the desired input/output patterns. A map, without dictating internal implementation details, to a working solution. I think you've identified some weaknesses in the track that also exist in the canonical specfile. |
|
OK, as far as I'm concerned I understood you correctly. |
|
OK, here is the discussion in the canonical track: |
1faff53 to
ca460e0
Compare
|
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. |
|
*i'll open it again when the time is ready (just came back from a vacation anyway). |
The spec file had some strange tests that are not really worth teaching to new devs.
I think we should really have an eye on proper test conventions when reviewing.
(this also is the case for other exercises, but I've only done this for now)
What do you think about this version?
Better? worse? Something I could change?
I think my proposal has a nicer test progression from a TDD point of view and removes unnecessarily duplicated cases and utilizes jasmine's BDD-oriented test description syntax (I hope).