tag:blogger.com,1999:blog-20576845.post1406005652220114041..comments2024-03-15T16:44:45.322+01:00Comments on Ziobrando's Lair: The soap opera test antipatternAnonymoushttp://www.blogger.com/profile/00568728817611163214noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-20576845.post-86807705903500808282008-03-15T12:34:00.000+01:002008-03-15T12:34:00.000+01:00@PietroTesting on the presentation layer is often ...@Pietro<BR/><BR/>Testing on the presentation layer is often performed recording user activity, so it's no surprise it'll look like a script. Testing the service layer, or unit testing doesn't have to.<BR/><BR/>An interesting point made by Coplien in the video was that Testing "imposed" a service layer, making developers lose the focus on the user interaction happening on the GUI which is more related to concepts like usability or user experience that cannot be easily automated.<BR/><BR/>I am proud of the name, but your subconscious is telling us that you actually like soap operas, and also which one... ;-)Anonymoushttps://www.blogger.com/profile/00568728817611163214noreply@blogger.comtag:blogger.com,1999:blog-20576845.post-52012122350926620142008-03-15T12:27:00.000+01:002008-03-15T12:27:00.000+01:00@GiulioI like "House M.D." and "C.S.I." and this i...@Giulio<BR/><BR/>I like "House M.D." and "C.S.I." and this is my default approach in problem determination. I would like also a walking stick, so it's no surprise if I see (or pretend to) "patterns" in the test red flags.Anonymoushttps://www.blogger.com/profile/00568728817611163214noreply@blogger.comtag:blogger.com,1999:blog-20576845.post-52109862553464581152008-03-14T19:47:00.000+01:002008-03-14T19:47:00.000+01:00I'm totally skeptical about the use of automated t...I'm totally skeptical about the use of automated testing (and a strong believer in human testers) for web based app, actually the soap opera antipattern seems to me to be the very essence of automated tests for such cases. But what matters here is the name you found: its beautiful, beautiful, you surely deserve to baptize it!Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-20576845.post-2768853516880647562008-03-14T18:52:00.000+01:002008-03-14T18:52:00.000+01:00"the number of flag should tell you something abou..."the number of flag should tell you something about the depth of the error"<BR/><BR/>In my experience this has seldom happened. Possibly because I like to keep the arrangement of tests independent from the real code, in order to avoid tautological (aka useless) tests.Giulio Cesare Solarolihttps://www.blogger.com/profile/10091367485831964592noreply@blogger.comtag:blogger.com,1999:blog-20576845.post-14963519227129725752008-03-14T18:20:00.000+01:002008-03-14T18:20:00.000+01:00Hi Giulio,the number of flag should tell you somet...Hi Giulio,<BR/><BR/>the number of flag should tell you something about the <I>depth</I> of the error. And if your tests are layered, then they'll help you locate the error. A surface error should raise few flags, a deeper one should raise a lot, but if you look at the test by layer you'll get a clue about where to watch.<BR/><BR/>Of course, tests are only <I>one</I> tool in play. Debugger is another one. Knowing what <I>you</I> just typed in helps, like checking the SCM log or the continuous integration system, if you have one.<BR/><BR/>In general, one single error is easy to find. Tons of error are easy as well. Some uncorrelated errors are a more interesting puzzle.Anonymoushttps://www.blogger.com/profile/00568728817611163214noreply@blogger.comtag:blogger.com,1999:blog-20576845.post-57476810043399887412008-03-14T18:06:00.000+01:002008-03-14T18:06:00.000+01:00Great post!With a single flaw, IMHO, when you say ...Great post!<BR/><BR/>With a single flaw, IMHO, when you say that "[...] a well formed test suite will help you a lot in problem determination by pointing right to the root cause".<BR/><BR/>In my experience, the more the structure/architecture of tests and of the real code are independent, the better.<BR/><BR/>This implies that a single change in the real code could trigger multiple tests and raise a lot of flags. It also implies that you don't have an immediate clue on what is going wrong when a light turn red.<BR/><BR/>But you are free to improve the architecture of your code without having to keep the test suits updated.<BR/><BR/>Unit tests are not a debugging tool. They are a confidence building tool.<BR/><BR/>You sometime add some tests just to help you "debug" your code, but usually these tests are very implementation specific. If you need to change the implementation, better throwing away all such tests and eventually write new ones, if this may help.<BR/><BR/>But I admit that it is not always easy to sort out which are the architecture specific tests (to keep no matter what) and which are the implementation specific one (that can be safely thrown away).Giulio Cesare Solarolihttps://www.blogger.com/profile/10091367485831964592noreply@blogger.com