Nice point.

Not used to this testing framework.

Thanks for info, should be fixed!

I hope that i managed to fix it all now.

Improved description, used some of your wording.

Hope that now it is more clear.

Should be fixed ;)

Posted by mistake, wanted to check it, why it is passing current validation...

Updated description, tests and function declaration

Added test case which invalidates it.. but i also don't know kind of magic this is ;)

Change requirements of kata, so.. it also invalidates this (and others) solutions.

Updated description, hope it will be now clear.

Oh, now i understand what you meant.

Today i learned one more thing about js. Thanks. Will fix.

1. Ok, then i will extend description, that magic square has to follow arithmetic progression, which can start from any number (which does not have to be 1) and the gap can be != 1. So it would be more clear for people less familliar with arithmetic progression.

2. Yes, I will have to modify description and tests, but i believe that it is worth to keep the kata going (mainly to not be solved by hardcoded values) instead of being duplicate. So if you agree that this change will help - then i will implement is soon.

1. I didnt update description yet, because im not sure about it.

Lets see:

• user won't have to implement such transformations
• user will have to read (not short) text about transformations which can confuse him

So i still think its better to change wording in tests:
e.g. Magic 3x3 Square should be valid after safe transformations change into:

8 1 6
3 5 7
4 9 2
should be a magic square

which would be more descibetive and less confusing.

What do you think?

2. And what about adding custom rule? Should i implement it and add to description?

Fixed, thanks for suggestion!

By custom rule i meant with the given value.

E.g. expected custom value is 2, so values:

1, 3, 5, 7, 9, 11, 13, 15, 17
are valid.

Then even when square X is magic, but its values are:
1, 2, 3, 4, 5, 6, 7, 8, 9 (progession by 1 not by 2)
then is should not be consider valid (because it does not follow "given up front" value) -> which is (ofc not hard) but some additional logic.

And the point that this kata connot be solved by hardcoded magic squares still stands as anti-duplicate in my opinion.

You are right.

It's relict of old interface before (new ideas) changes applied. I missed this one to updated by undefined params.

And you are right, for normal use the filter object would make sense. I kinda didnt want to add more boiler plate things and didnt expect (at first) so "many" params.

Test fixed.

Thanks for feedback!

Working on fixes.

• modified description

• Added missing tests.

• Changed base logic (undefined count should be replaced with default value: 1) (and modified description)

• Added sample tests for removes

• about empty name.. it seems kinda logic, but.. noone said that empty string is invalid name. so.. empty string as filter doesnt seems to be sth which (right now) should be treated as optinal.

i wonder if its better to change description (so empty string is invalid name) or add validation if someone (by mistake) didnt treated it as optional