Which is pretty much what I did, though I used Haskell. But why do it that way to begin with? I just fail to see the reason for it!

All you really need to do is setup

class Node (object):
  pass

Why hide away the Node type in a private module? It means one is forced to program in the browser rather than using one's favourite editor and local setup!

Well, in most languages this can be done with regular expressions

I marked it as an issue since it's a question regarding behaviour that suggests it's an issue with the test ;)

My original solution (not the one I submitted), does handle isValidWalk $ repeat 'n' just fine, but the test never returns.

Nice, but it doesn't work on quite a few languages of course.

This isn't an issue, but a question. That aside, the test for infinite lists is

it "should reject infinite walks" $ do
  property $ forAll infiniteList $ \walk ->
    if isValidWalk walk == False
      then return ()
      else expectationFailure "this infinite walk should have been rejected"

The only function that could actually evaluate the list is isValidWalk. Does your solution also handle isValidWalk $ repeat 'n'?

If you need more help, post it in a comment, but mark it as a spoiler.

I'm stuck on the code in Test.hs with infinate walks. That is, my solution handles this:

isValidWalk (cycle "ns")

but when running the provided test code the test never terminates. Is there something that's too strict in the test (so the infinate walk is evaluated)?

but why call that function "=="?

Because shouldBeFuzzy uses shouldBe, which uses (==) :: Eq a => a -> a -> Bool. That's actually the reason I use FuzzyDouble, so that I can "override" the behaviour of shouldBe for Double. That way, I didn't had to write the following code:

shouldBeVia :: (Show a) => (a -> a -> Bool) -> a -> a -> Expectation
shouldBeVia f a b = if f a b then return () else expectationFailure $ "Comparison between " ++ show a ++ " and " ++ show b ++ " failed"

shouldBeFuzzy = shouldBeVia (\a b -> ...)

Which, to be honest, seems actually smaller. Meh.

Yeah, it's definitely the right way to compare doubles and the second piece of code looks good, but why call that function "=="?

Don't you think it's a bad practice?

In general, yes. However, using equality tests on Double is usually bad, given that (+) :: Double -> Double -> Double isn't associative. For example, the following loop might not halt (depends on the used floating point type, equality test, and interpretation of literals):

for(float i = 0; i != 1.7; i += 0.1){
  ...
}

At least (==) :: FuzzyDouble -> FuzzyDouble -> Bool is still symmetric and reflexive. Also, none of the types are exported.

That == doesn't look transitive. Don't you think it's a bad practice?

module Codewars.Kata.Test.DSL (given', shouldBeFuzzy) where
import Data.Function (on)
import Test.Hspec (Expectation, Spec, it, shouldBe)

infix 0 `shouldBeFuzzy`

given' :: (Show a, Show b) => (a -> b) -> a -> (b -> b -> Expectation) -> b -> Spec
given' f xs t ys =  it ("works given " ++ show xs) $ f xs `t` ys

shouldBeFuzzy = on shouldBe (map MkFuzzy)

-- Enables relative error checking in Double...
newtype FuzzyDouble = MkFuzzy { getFuzzy :: Double }
  
-- ... still looks like Double...
instance Show FuzzyDouble where
  show = show . getFuzzy

-- ... but uses slightly other equality semantics.
instance Eq FuzzyDouble where
  (MkFuzzy a) == (MkFuzzy b) = abs (a - b) / maximum [1e-15, abs a, abs b] <= 1e-10

However, you can shorten it to

    given' f xs _ ys    = it ("works given " ++ show xs) $ f xs `shouldBeFuzzy` ys
    itReturns           = undefined
    shouldBeFuzzy us bs = us `shouldSatisfy` (all (\(a,b) -> abs (a - b) / maximum [1e-12, abs a, abs b] <= 1e-10) . zip bs)