Test to Break Principle

Replace the “60% of the time” quote with developers looking for bugs under a streetlight https://en.m.wikipedia.org/wiki/Streetlight_effect

Excellent talk by Rob. Very open to suggestions for his talk (and a few ideas that I will be "borrowing" for my own talks).

Slides were perfect, and Rob didn't fall into the trap of talking from the slides (many talks do that)?

Brave of Rob to do a 'live' demo, he did very well with it, and the only improvement to this is to have it pre-recorded (pretend to type), and then you don't need to worry about typos or possible errors ;)

I love your subtitle. I'm interested to know what got you on CNN!
I like the big text over big uncluttered images.
I like the analogy of someone who actually tries to break physical cars. V relatable.
I like calls for a round of applause, it's good to see audience engagement.
I like the recognisable format of your test cases.
I'm glad you gave the example of a good fail (airbags) and a bad fail (explodey killy) because I think many people would think that crash = fail and not think into failing gracefully.
I thought that going through the different "facetious" test cases was a bit slow, but then your humorous summary made it perfect. I thought the line "I've done my job, I can go home now" was hilarious!
A bug I had recently that was more unexpected to me and an easy mistake to overlook, was a numerical field that accepted any valid number... Including octals, hex and binary. Test to break caught that...
Thanks for teaching me about assertSame!
Thank you!! I love this subject and the truth is that test to break is really fun to do!

I liked your message. ?

I think it would have been good to use data providers in your unit test examples as it would show people that it's easy to create tests with multiple sets of inputs. With your current examples, people may get the impression that you have to copy and paste single-line tests to cover a lot of different scenarios.

Enjoyed the talk. Learned a couple of really useful bits about PHPUnit too.

Suggestions for improvement are very minor. I'd go faster over the acceptance criteria slides. No need to read them fully.

Would also have the string concantination ready to copy paste rather than type out. Only as a pacing thing.

Really great talk, good expansion of the subject, and made me laugh. Only suggestion would be to consider showing exception testing within the method as well as in the comment, for consistency with the rest of the tests, and because the content font colour want very readable.

An engaging talk emphasising the importance of good test coverage.

I think the live demo worked well and was smooth enough to keep audience engagement.

Yes enjoyable talk by Rob. It sent me off down a rabbit hole learning about Mutation testing. Wish I had sat nearer the front, will do that next time perhaps. Thanks Rob!

Liked the diverse background bits and use of live coding to illustrate tricky concepts. As someone who already uses and appreciates the value of test, I am not sure this really got to the heart of the problems involved so was left wanting more technical depth.

Good talk, really well organized.
As a suggestion, don't be afraid of waist a bit more of time with the examples (or not use them at all).

I'm ready to break my car!

Really enjoyed the talk and definitely agreed with the points made. The pace and delivery were spot on in my view; the courageous live coding demo was very effective.

The only thing I'd add is to give a very brief definition of what a unit test actually is (just a few words rather than a lesson), if somebody hasn't seen one before they might be a bit lost.

Rob, thank you for your talk - it was excellent. I have only a few minor items of feedback, and I put them them forward knowing I could not possibly have made a better job of it. I hope they are helpful.

There were several mentions of the word "obviously" when a point was being made. This is probably not necessary - some things that are obvious to senior engineers may not be obvious to juniors. Indeed, I think it is fine to state first principles and base assumptions, even if it is a basic as wanting your car key to start your car.

There was a section on working code where you mentioned "bug free code", and I was going to make a point that there is no such thing - and then a couple of minutes later you beat me to it - "bug free as humanly possible". That was very good. My only remaining feedback here is that the main sub-point may have taken a bit of time to emerge.

A couple of times the screen could have done with being higher, or the slides not reach all the way to the bottom - from the back, the material at the bottom was cut off by people's heads.

Finally, I experienced some amusement when I thought I heard you say "famous communists like Milton Friedman". Perhaps I should get a "herring aid"! I presume you said "economists" :-)

Good talk and I liked the overall message, essentially "test more than the happy path".

Good delivery, I liked how you engaged with the audience.

If you're going to live demo anything then TDD is the thing to live demo. For future talks see if you can change the colour, the live demo was not the easiest to read at the back.

I wonder if you could pick a different example to illustrate test to break. If I were doing TDD then I think you'd cover off most of the examples in normal 'happy path' testing.

However if you did something like the roman numerals kata, you could show working tests for the happy path range, say 1 to 4000. But then ask for your test to break, what happens if someone provides a negative number. Or a number like 1 million.

Good luck at PHP-UK.