Test your problem solving (exercise)


(Adré Du Toit) #1

This isn’t strictly about coding (or at least, programmers aren’t the target audience), but I found this exercise @skinofstars pointed me to said some pretty interesting things which relate very strongly to writing code. I don’t want to give anything away, but take a look and then come back here so we can discuss how you did:


(Daniel Hollands) #2

I got it right. That’s all I can say about it now without giving anything away.


(Steve Pitchford) #3

( I got it right )


(Stuart Langridge) #4

I just get asked to log into my new York times account?


(Daniel Hollands) #5

That’s unusual, I’ve just looked again, but nothing like that is happening for me.


(Stuart Langridge) #6

Works on desktop. Test passed. Although this is because (rot13ed spoiler) V erpbtavfrq vg nf n grfg sbe pbasvezngvba ovnf.


(Daveyon Mayne) #7

I figured out that the numbers must be bigger than the first etc


(Adré Du Toit) #8

I think it’s more than a question of right and wrong with this exercise, but then that may be because I got it wrong and I’m looking for deeper meaning and redemption. For me, the number of passing and failing tests written is also quite telling.

I had three passing tests and thought I had the answer, but as @sil points out, it’s classic confirmation bias. In retrospect, I should have been looking for a ‘no’ on at least my second test. On the flip side, other people I spoke to about this ended up with a dozen tests with pretty much a 50/50 split of ‘yes’ and ‘no’ responses.

I wonder now whether this says something about the way we write tests for code - or perhaps how we should write our tests. Could an exercise like this give one an idea of whether their tests are too verbose or not detailed enough? Is a dozen checks too many or is it about optimal for this exercise? Could 3 checks be sufficient if you’re checking the right things?


(Stuart Langridge) #9

It’s not about the quantity, I think, so much as it is about testing alternatives. If you’ve got a unit test which, say, confirms that your JavaScript correctly adapts a input type=number into a “dial”, then that’s great, but does your test also try giving it two inputs and confirming that it works on both of them? What if the input doesn’t have an id? That sort of thing; testing is not just about “does it do the right thing given ideal circumstances”, but also “does it do the right thing in other circumstances?” Whether that “right thing” is to handle it correctly, or to throw an error, or to silently not work… that’s all fine, as long as it’s what’s meant to happen and the test suite confirms that.


(Steve Pitchford) #10

After Being smug and guessing the answer I realised that my answer still contained confirmation bias - I hadn’t tested two factors ( I’m sure there are others ):

  1. negative & zero numbers ( such as the range -1,0,1 - to ensure that the range wasn’t limited to positve numbers )
  2. Range - certain numbers such -129, + 128, 257, and others such as n9’s would have been sensible to test in case of upper or lower boundary.

Having said that - started the problem, out of habit, with an informal risk assesment and realised I didn’t have a lot to loose, and potentially something to learn with a quick punt after a few guesses.