Retired
// (retired)
Loading description...
Algorithms
Arrays
Data Types
Fundamentals
View
This comment has been reported as {{ abuseKindText }}.
Show
This comment has been hidden. You can view it now .
This comment can not be viewed.
- |
- Reply
- Edit
- View Solution
- Expand 1 Reply Expand {{ comments?.length }} replies
- Collapse
- Spoiler
- Remove
- Remove comment & replies
- Report
{{ fetchSolutionsError }}
-
-
Your rendered github-flavored markdown will appear here.
-
Label this discussion...
-
No Label
Keep the comment unlabeled if none of the below applies.
-
Issue
Use the issue label when reporting problems with the kata.
Be sure to explain the problem clearly and include the steps to reproduce. -
Suggestion
Use the suggestion label if you have feedback on how this kata can be improved.
-
Question
Use the question label if you have questions and/or need help solving the kata.
Don't forget to mention the language you're using, and mark as having spoiler if you include your solution.
-
No Label
- Cancel
Commenting is not allowed on this discussion
You cannot view this solution
There is no solution to show
Please sign in or sign up to leave a comment.
Random tests can generate
[]
as an input.This is a problem.
You can't use normal equality with floating point values ( and rounding is not going to be a solution ); you have to allow an error margin. Write your own wrapper specific for your output encoding ( which is also bad, bad, bad ).
When do we return a nested array (
[1,3,4,5]
) and when do we returnnull
? I actually see no problem with multiple modes - arrays are not limited in length and1,3,4,5
are all occurring equally often.In the discription I was doing it in such a way that if all the numbers were the same frequency and none were more than the other then return null. should I do it differently?
I think
I've changed the description
I solved it by requiring the frequency of the mode having to be
> 1
. That doesn't make much sense.The description is too long anyway. Simplify things ( a lot ), and take out any such logical inconsistencies. There is always a mode ( unless the input is
[]
). ( Is that tested? No, it doesn't have a mean either. This should be specified. )You fixed it wrong. Well, less than ideal.
If you're wrapping one block in
describe
, wrap all blocks indescribe
, orchai
will reorder and format your tests in weird ways.You can nest
it
s indescribe
s anddescribe
s indescribe
s, but notdescribe
s init
s orit
s init
s. The outermost level of wrapping can beit
s ( if it's the only level ); the innermost level must be. There is no need to show the input in the header anyway ( people can debug print that themselves if they need to ), so use wrappers to group tests, not to show endless useless information. ( Other opinions may be available, but I favour a rather minimalistic look of test results. )Returning inconsistent datatypes is not a best practice.
Not raising an
Issue
without a specific example, but mean and mode have been done before. This feels like a duplicate.OK, realistically, this is going to be retired sooner rather than later.
Your next attempt at publishing a kata should really have less problems - preferably none at all - when you hit
Publish
. Read the docs; if you don't know something, ask for help before publishing ( docs say where ), and don't cut any corners. Also, pick an original subject for your kata. Or the next one will probably get retired again, which is good for no one.Node v8.1.3
Why use an obsolescent version?
You are even already using
chai
!I couldn't figure out how to get the random tests to work without that version. It's probably somthing really obvious, but I'm new to testing. I'm not sure i understand it. can you help me?
Yeah, let me finish the kata and I'll have a look.
Thank you!
You have to correctly wrap
assert
s indescribe
s andit
s.I think you only have to wrap in
it
s inNode 12.x
.ATM, there are no random tests if you just choose
Node 12.x
in the drop-down. That's a problem. Fix that now.Fixed! Thanks