2015 Madison PHP Meetings
1 Jan - 31 Dec 2015 at Madison College

Enjoyed the philosophical discussion of testing schools of thought and in depth look at different test doubles (e.g. not everything is a "mock"). As someone who doesn't currently test, it is definitely encouragement towards at the very least implementing some testing if not implementing TDD principles.

I thought this was a great talk. I haven't been able to get into doing TDD, but I know I need to. This gave me the inspiration to really look harder at doing TDD in the London style.

I really enjoyed this talk. I had never heard of the different camps of tdd. I've only started testing fairy recently but haven't done tdd. I'm now very interested in trying it out on my next project and figure out how to use tdd to improve the design of my current app.

Matt did a great job talking about mocking from a high-level and provided some interesting examples for handling things like mocking PDO connections and statements. Great talk and a fun speaker with a lot of humor! My favorite was, "if you don't mock your dependencies, you're gonna have a bad time."

Great talk -- worth the long drive in the snow and traffic. I like the practical advice. For example, don't waste time testing getters and setters. And draw clear lines where not to to test -- verify the sql string that gets created. I would have tried to mock the database and return mock values, which would be a time-consuming mess I think.

There aren't many recent books on the subject, so this talk fills a need. Maybe Matt should write a book?? Or maybe a lynda.com-like series of videos going in depth.

One problem I have with these mock objects is that I don't have a mental model of how they actually work. They're like magic/pychic php objects. I think this lack of understanding on my part is making it more difficult to get comfortable with them. I realize that this is not practical to cover in a 1.5 hour intro talk. But if Matt or someone could blog about it, that would be helpful. (I'm assuming I'm not the only person who thinks this way. I could be wrong.)

I'm curious about what Matt or anyone else thinks about the practicality of TDD: Write the test first, watch it fail, then write code until it passes. Is this actually doable? It would mean 100% code coverage, which contracts the concept of don't test the simple stuff. Is TDD actually a waste?