The "meat" of this talk is IMMENSELY useful. I sincerely hope he can make it more dynamic or something - the monotone is a huge drawback. (Seriously, the refactoring he does on the test, progressively reducing it from 30+ lines down to a few is fantastic.)
Where would you try to find the information? When I was a student one of my IT teacher told something like this: "Information: Either you know it, either you know where to find it" Hints: Beginning of presentations often start with presenter's name + here at least the guy put his name on every slide at the bottom.
When we look at What Gerard Meszaros is describing in automated testing gotchas, the gotchas not related to coding style and refactoring are all things manual testers do already. Smells emanating from random behaviors, fragility, uncertainty coming from the appearance of your fixtures (environment setup steps) and test run wars are real manual test problems too. The issue is that automation engineers really must guard especially well against making these mistakes, to keep testing cost down. Maintainability debt is your greatest enemy, and where I personally prefer less not more automation - "too many test-cases" is a smell I detect, one not explicitly mentioned in this talk. I'll be looking for a copy of xUnit Test Patterns!
Hopefully, you've got your answer already. If anyone else needs to know: The Author is Gerard Meszaros. His book is called xUnit Test Patterns published with Addison Wesley and signed by Martin Fowler.
The only explanation I could give is the projector has a very untypical angle to display content. Or he is not actually where we seem to see him. Basically illusion on his position.
There is STRONG pressure to just get it done, what happens in a lot of cases is people are pushed to get working code and aren't given enough time to make good tests. There will never be enough time to test every path in the code, so its a trade-off. What's more important? Hitting the deadline? ensuring maintainability? Is a bug disastrous or just an annoyance? its depends on the requirements. TDD is also very VERY addictive and fun. BONUS if you can get test results in under 0.1 seconds, it literally feels like a video game. Seriously if any developer wants to improve their happiness factor at work, they should work on getting there test framework to return results almost immediately, it is a night an day difference in the level of engagement of the task.
That's true. There is too few examples compared to what is provided when you lack experience mostly. If you wen t through similar situations you can relate to these however.
"About the same unit test code as production code." That's really a pearl. How insightful and at the same time, how simple.
The "meat" of this talk is IMMENSELY useful. I sincerely hope he can make it more dynamic or something - the monotone is a huge drawback. (Seriously, the refactoring he does on the test, progressively reducing it from 30+ lines down to a few is fantastic.)
NICE ONE@
@Quinzio,....s i agree wid u...can anyone pls give me sme practical examples on different types of testing...
Who is the author of this talk. and what book did he write?
Where would you try to find the information?
When I was a student one of my IT teacher told something like this: "Information: Either you know it, either you know where to find it"
Hints: Beginning of presentations often start with presenter's name + here at least the guy put his name on every slide at the bottom.
When we look at What Gerard Meszaros is describing in automated testing gotchas, the gotchas not related to coding style and refactoring are all things manual testers do already. Smells emanating from random behaviors, fragility, uncertainty coming from the appearance of your fixtures (environment setup steps) and test run wars are real manual test problems too. The issue is that automation engineers really must guard especially well against making these mistakes, to keep testing cost down. Maintainability debt is your greatest enemy, and where I personally prefer less not more automation - "too many test-cases" is a smell I detect, one not explicitly mentioned in this talk.
I'll be looking for a copy of xUnit Test Patterns!
Very useful video. Many thanks to the author.
Also, let me recommend "Blisk Browser" as a very powerfull tool for testing
what the heck is this? my test doesn't smell.
Hopefully, you've got your answer already.
If anyone else needs to know:
The Author is Gerard Meszaros. His book is called xUnit Test Patterns published with Addison Wesley and signed by Martin Fowler.
If he stands between projector and the screen why is his face dark!?
The only explanation I could give is the projector has a very untypical angle to display content.
Or he is not actually where we seem to see him. Basically illusion on his position.
Why don't more software engineers code their tests like this?? Sigh
There is STRONG pressure to just get it done, what happens in a lot of cases is people are pushed to get working code and aren't given enough time to make good tests. There will never be enough time to test every path in the code, so its a trade-off. What's more important? Hitting the deadline? ensuring maintainability? Is a bug disastrous or just an annoyance? its depends on the requirements.
TDD is also very VERY addictive and fun. BONUS if you can get test results in under 0.1 seconds, it literally feels like a video game. Seriously if any developer wants to improve their happiness factor at work, they should work on getting there test framework to return results almost immediately, it is a night an day difference in the level of engagement of the task.
It is very annoying about your camera man frequently zooming in and out. Please do not do that any more.
All this theoretical talk without any example is just useless.
This is practical worl, we need examples.
That's true. There is too few examples compared to what is provided when you lack experience mostly. If you wen t through similar situations you can relate to these however.