I see this sort of thing every day. Fast forward to 5:05 and we hear like “I assert the values..” and then fast forward to 17:45 and line numbers 29, 30, 33, 34, 37, 38, 42 & 43. My question is simple: who decides that the value to assert is one or two? If the contradiction is not obvious then try to answer as a) programmer / IT or b) business. If the business states their requirements and defines the values to assert then how does IT engage the business in something as abstract as programming? If the programmer asserts the values then how to ensure the programmer assumes the correct values to assert? If the business explains what values to asset then what should we do to prevent the programmer asserting the wrong values? What I am missing from this is something that prevents us creating an efficient feedback loop to do the wrong things quickly.
The business people define the acceptance criteria, because acceptance criteria need to specify behavior that drives business value, and they are the people whose job it is to understand the business, not the technical people. Even more than that, they get to decide which piece of business value is the highest priority item, and that's what you work on next. If your business people are stepping outside of their wheelhouse and handing you technical details, then you have a massive problem. If they don't trust their technical people to make the technical decisions, or if your business people are incapable of delivering business-value-driven acceptance criteria, then yeah your company is going to fail and the best you can hope for is your business fails quickly so everyone can move onto something viable.
At 8:19 we see one risk in using the most generic error type to signal a test failure. :) I was wondering which test would catch the problem. Fortunately, with so little code, the mistake didn't do much damage! (I see a clue in that sentence.)
If I was moving a little slower that would have been a good idea, the special purpose AssertionError. I'll be damned if I'm going to re-record the whole thing *again* just because I made a mistake, though :)
Hi Kent, this was great! I just found out that you can write the following, at least in current version of Coffee Script (1.12.2). result = CSUnit.runAll [(->), (->)] Perhaps doesn't look pretty...
More like this! Thanks for taking the time to put this together Kent. Always love peering into your process and how you approach solving problems.
Mindblowing. There is soooo much to learn from your style of thinking... I thought that I am familiar with TDD. Turns out I'm not :)
Really enjoyed this. Thanks for sharing :-)
Great little video because reasons!
I see this sort of thing every day. Fast forward to 5:05 and we hear like “I assert the values..” and then fast forward to 17:45 and line numbers 29, 30, 33, 34, 37, 38, 42 & 43. My question is simple: who decides that the value to assert is one or two? If the contradiction is not obvious then try to answer as a) programmer / IT or b) business. If the business states their requirements and defines the values to assert then how does IT engage the business in something as abstract as programming? If the programmer asserts the values then how to ensure the programmer assumes the correct values to assert? If the business explains what values to asset then what should we do to prevent the programmer asserting the wrong values? What I am missing from this is something that prevents us creating an efficient feedback loop to do the wrong things quickly.
The business people define the acceptance criteria, because acceptance criteria need to specify behavior that drives business value, and they are the people whose job it is to understand the business, not the technical people. Even more than that, they get to decide which piece of business value is the highest priority item, and that's what you work on next.
If your business people are stepping outside of their wheelhouse and handing you technical details, then you have a massive problem. If they don't trust their technical people to make the technical decisions, or if your business people are incapable of delivering business-value-driven acceptance criteria, then yeah your company is going to fail and the best you can hope for is your business fails quickly so everyone can move onto something viable.
At 8:19 we see one risk in using the most generic error type to signal a test failure. :) I was wondering which test would catch the problem. Fortunately, with so little code, the mistake didn't do much damage! (I see a clue in that sentence.)
If I was moving a little slower that would have been a good idea, the special purpose AssertionError. I'll be damned if I'm going to re-record the whole thing *again* just because I made a mistake, though :)
Hi Kent, this was great!
I just found out that you can write the following, at least in current version of Coffee Script (1.12.2).
result = CSUnit.runAll [(->), (->)]
Perhaps doesn't look pretty...
something was wrong with the formating... here it goes with white space...
result = CSUnit.runAll [( - >), ( - >)]