tag:blogger.com,1999:blog-34454975.post5623774948951873390..comments2023-06-28T16:58:41.189+02:00Comments on Web Reflection: My BerlinJS SlidesAndrea Giammarchihttp://www.blogger.com/profile/16277820774810688474noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-34454975.post-79498431723896748882011-12-25T15:08:00.812+01:002011-12-25T15:08:00.812+01:00This comment has been removed by a blog administrator.Nataliehttp://www.copperbasin.com/find-your-home/post-falls-idaho/noreply@blogger.comtag:blogger.com,1999:blog-34454975.post-90053592906605406612011-10-25T23:43:45.876+02:002011-10-25T23:43:45.876+02:00- it does make people to think what they have deve...- it does make people to think what they have developed ... at least what they think they did works with a proof<br />- you test against what you thought you coded ... fair enough, since real world case and humans problem will come later, at least you can guarantee a behavior<br />- flexibility/agile must work and tests are a way to proof stuff is "working out" as expected<br />- test must be maintained/updated as soon as API changes or even before so the proof things work is still there<br />- time is against software quality so it's a weak point unless you don't want to live out of a "maintainance contract" using customer ingenuity<br /><br />Most important thing ever: <b>I have never talked about TDD</b> in my slides or, generally speaking, in this blog. TDD is for ExTreme Development and since perfect software does not exist yet anywhere in this world, I am not the one that tells people "<i>hey, you do TDD, it must be best software ever</i>" ... I am here the only one that is trying to make tests easy: <b>wru</b>!!!!Andrea Giammarchihttps://www.blogger.com/profile/16277820774810688474noreply@blogger.comtag:blogger.com,1999:blog-34454975.post-73997967189616004642011-10-25T23:24:23.609+02:002011-10-25T23:24:23.609+02:00Place here didn't mean geographical place.
M...Place here didn't mean geographical place. <br /><br />My problem with TDD boils down to a few points basically:<br />- It does make people think that they can go a good job independent of the actual result (eg. tests passed, yet the application isn't good), and this is especially a case where everyone does the best possible yet the end result isn't mindblowing so to say.<br />- You don't test against humans, you test against a computer, which sometimes makes the actual system fail miserably in real-life situations<br />- I'd like to question TDD- based code's flexibility. I found FitNesse to break under any real-world use cases for example<br />- Tests maintained by the developer himself (herself) tend not to clean up APIs, and if combined with missing design (prev. point), zoomout tends to be missing.<br />- Personally, for me, hardcore TDD breaks my code cycles of 1-1.5 hours where I could think straight<br /><br />While for API-kind of development, especially with complex business logic, I do write unit and acceptance test and ask everyone to do so, and it's a great tool to imagine an API (although only as a side activity), it's also great sometimes to explain (and come up with) specification details I doubt if it should be used as a substitute for traditional design technologies (pattern languages, design languages, other half-explicit languages) as it is today.Aadaamhttps://www.blogger.com/profile/05843560041038857258noreply@blogger.comtag:blogger.com,1999:blog-34454975.post-13110190595282947922011-10-25T22:27:18.691+02:002011-10-25T22:27:18.691+02:00"a place for abstraction" is over engine..."<i>a place for abstraction</i>" is over engineered for real world use cases but still, you can have that without problems. Create a place out of an empty representation on the map and you are done.<br /><br />In any case, <b>wru</b> aim is to bring people that do not test at all their code into "<i>at least something works as expected</i>" world without any TDD paranoia and once again, this blog is not about my daily basis work, it's about programming!Andrea Giammarchihttps://www.blogger.com/profile/16277820774810688474noreply@blogger.comtag:blogger.com,1999:blog-34454975.post-9942099644287192882011-10-25T03:54:06.085+02:002011-10-25T03:54:06.085+02:00Hey man,
I see you're fascinated by TDD.
Y...Hey man, <br /><br />I see you're fascinated by TDD. <br /><br />Yet my question is: does it really solve the problem?<br /><br />Let's see this not-so-imaginary problem: the user needs a convenient way to access Nokia Maps data from his iPhone.<br /><br />Of course, Gaia is great, yet unfortunately, the solution to this is not just Gaia itself, but rather an application built around Gaia.<br /><br />Now the specification of this application isn't defined by you. You can talk into it perhaps to an extent, but at the end, you'll have a specificaition, which you can turn into a test.<br /><br />Is the application good if it doesn't fail any of those tests and they cover all the relevant parts of the specification?<br /><br />Also, what if you failed to recognize some inter-relatedness (like: a place for abstractions) in the specification? What if the system fails to deliver as such isn't addressed in the system?<br /><br />It still passes all the tests. <br /><br />I've written partly about it in the long comment here:<br /><br />http://www.infoq.com/articles/specification-by-example-book#view_77233Aadaamhttps://www.blogger.com/profile/05843560041038857258noreply@blogger.com