animated personality fully capturing attention. Practical stories and similies effectively getting the point across. I did not understand the difference between BDD test and Unit Tests but after his introduction it became clear to me what each one does. Real job problems are well tied to theoretical defintions. Clear transition from general discussion to technical details (eg. gherkin example).
Well prepared with ready to go git branches to follow. I consider this a critical component of a tutorial. This made experience less stresful knowing there is a path for me to follow. Also great for studying the material after the presentation. Following along through the command samples and code in the repository was very entertaining and educational. Important issues audience should get just right to not have problems are well highlighted. Very good progression starting from non-existing code, to broken test, to fixed code, pointing out what every output means and how it relates to the code.
One thing I think needs improvement is not having each step as throw away. All work done in one branch was reset when moving to next branch and next branch had code previous one did not, as opposed to using branches as "safe checkpoints" if mess up. I also did not realize for some time that the php file is not actually the code being tested, that the .feature describes and does some semantic analysis to know what functions to run, but was actually the test code against the subject API.
My favourite talk hands-down. I hadn't read the talk description, so I wasn't expecting a BDD talk. I probably wouldn't have gone if I knew it was, but I'm really glad I did. Keith is an extremely compelling and engaging speaker. I really gained an appreciation for what BDD does for you, and I'll definitely be using it for client projects immediately.
It was a great talk. It felt very natural and not forced, but I should echo a previous comment that I had looked at the talk as being more of an API talk and not a BDD talk. I enjoyed it as I am actually pushing myself into testing more and more, so I did certainly appreciate the insights into BDD, but didn't get much in the way of testing API's as much.
The use of Github branches (github.com/caseysoftware/is-your-api-misbehaving) for all the different steps of the tutorial was super helpful. There was also a clearly established routine for each exercise - generate the test functions, fill them in, evaluate results, repeat. This felt a little repetitive, but I think in this case that's a good thing - I knew what to expect and it was easier to absorb the information, with principles being reinforced each time.
I found it really easy to follow, but if I had only the github tutorial / code I would have a harder time figuring out what was going on. I would maybe flesh out the readme a little more with some directions on how to run through example scenarios and which files to pay attention to, in case people want to refer back to it or share with people who didn't attend. There are only a couple files that are changing with each step, so this is an easy thing to add that would really help.
Comments
Comments are closed.
Thank you learned a lot!
animated personality fully capturing attention. Practical stories and similies effectively getting the point across. I did not understand the difference between BDD test and Unit Tests but after his introduction it became clear to me what each one does. Real job problems are well tied to theoretical defintions. Clear transition from general discussion to technical details (eg. gherkin example).
Well prepared with ready to go git branches to follow. I consider this a critical component of a tutorial. This made experience less stresful knowing there is a path for me to follow. Also great for studying the material after the presentation. Following along through the command samples and code in the repository was very entertaining and educational. Important issues audience should get just right to not have problems are well highlighted. Very good progression starting from non-existing code, to broken test, to fixed code, pointing out what every output means and how it relates to the code.
One thing I think needs improvement is not having each step as throw away. All work done in one branch was reset when moving to next branch and next branch had code previous one did not, as opposed to using branches as "safe checkpoints" if mess up. I also did not realize for some time that the php file is not actually the code being tested, that the .feature describes and does some semantic analysis to know what functions to run, but was actually the test code against the subject API.
My favourite talk hands-down. I hadn't read the talk description, so I wasn't expecting a BDD talk. I probably wouldn't have gone if I knew it was, but I'm really glad I did. Keith is an extremely compelling and engaging speaker. I really gained an appreciation for what BDD does for you, and I'll definitely be using it for client projects immediately.
Great intro to BDD.
It was a great talk. It felt very natural and not forced, but I should echo a previous comment that I had looked at the talk as being more of an API talk and not a BDD talk. I enjoyed it as I am actually pushing myself into testing more and more, so I did certainly appreciate the insights into BDD, but didn't get much in the way of testing API's as much.
From a speaking perspective it was a very good talk. Very engaging.
However, I will echo the comments that it wasn't clear this would be a BDD talk, I thought more interesting api-specific problems would be addressed.
I'd also recommend rebasing on each step, rather than resetting --hard and throwing away the progress we've made.
Keith was a good presenter. I wasn't that familiar with BDD so I found this was a very informative talk.
Keith was a good presenter. I wasn't that familiar with BDD so I found this was a very informative talk.
Thanks very much...Presentation was quite informative.
Thanks for the feedback on this one. I sincerely appreciate it. :)
The next time any of you are in Austin, drinks on me. Well, one..
The use of Github branches (github.com/caseysoftware/is-your-api-misbehaving) for all the different steps of the tutorial was super helpful. There was also a clearly established routine for each exercise - generate the test functions, fill them in, evaluate results, repeat. This felt a little repetitive, but I think in this case that's a good thing - I knew what to expect and it was easier to absorb the information, with principles being reinforced each time.
I found it really easy to follow, but if I had only the github tutorial / code I would have a harder time figuring out what was going on. I would maybe flesh out the readme a little more with some directions on how to run through example scenarios and which files to pay attention to, in case people want to refer back to it or share with people who didn't attend. There are only a couple files that are changing with each step, so this is an easy thing to add that would really help.
Good talk and good energy!