tag:blogger.com,1999:blog-2441850399540300710.post6169360647714282684..comments2024-02-17T03:47:06.818-08:00Comments on CraigBlog: TDD Is Great...Except When It Isn'tCraig Anderahttp://www.blogger.com/profile/17084199593129216563noreply@blogger.comBlogger20125tag:blogger.com,1999:blog-2441850399540300710.post-66519678046249122812011-07-09T23:42:45.000-07:002011-07-09T23:42:45.000-07:00Thanks Ian, I wish that your explanations are supp...Thanks Ian, I wish that your explanations are supported with little examples, or links, it could be more thorough, as its a complex issue indeed.<br /><br />May be some one, will be interested in writing an example, showing mocks in action with GUI elements in WPF, it will be a great article indeed.<br /><br />Thanks again :-)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-2441850399540300710.post-62808452226558877332011-07-07T04:04:04.000-07:002011-07-07T04:04:04.000-07:00Thanks, I've sent him an email, and I will put...Thanks, I've sent him an email, and I will put his explanation here, as its in the heart of this thread :-)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-2441850399540300710.post-52698451325431028252011-07-06T04:19:39.000-07:002011-07-06T04:19:39.000-07:00It has been over a year since I've done anythi...It has been over a year since I've done anything Microsoft-related, and much more than that since I've done GUI stuff. I never really got into WPF. So I'm not totally sure. <br /><br />I will say you'll probably wind up with a variation of the MVC pattern, where you test your controllers and maybe your models, and have dumb views that don't get tested. But you should go ask Ian Griffiths - he knows a lot about all things WPF.craig-anderanoreply@blogger.comtag:blogger.com,1999:blog-2441850399540300710.post-58165690862139219062011-07-06T00:46:08.000-07:002011-07-06T00:46:08.000-07:00craig-andera, as you have gone through GUI testing...craig-andera, as you have gone through GUI testing long time a go, what's your advice when it comes to test a WPF application with resising adorners & drawing tool ?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-2441850399540300710.post-68858694025705042652009-11-30T16:29:07.000-08:002009-11-30T16:29:07.000-08:00@Niclas: well, I wrote this article about five yea...@Niclas: well, I wrote this article about five years ago - I'd likely do things differently now.craig-anderanoreply@blogger.comtag:blogger.com,1999:blog-2441850399540300710.post-6449949682030942992009-11-30T14:02:32.000-08:002009-11-30T14:02:32.000-08:00I just had to do this, sorry :-)
I think you are...I just had to do this, sorry :-)<br /> <br />I think you are just trying to go with the "i don't have time to test" or "it's to much effort to test". If your job depended on it, you would for sure do whatever it takes to test. In the end, supporting usercontrols is pain and the time invested in testing the code would for sure be worth the investment, no doubt.<br /><br />It is such a similar discussion to the one you can hear about data access and SQL.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-2441850399540300710.post-83877056859330019762006-02-10T04:37:00.000-08:002006-02-10T04:37:00.000-08:00I've certainly used hand-rolled mock objects t...I've certainly used hand-rolled mock objects to the same effect. In fact, I've done it with web services. <br /><br><br /><br>The fact that TypeMock is a commercial product pretty much guarantees that I'll never use it, though. <br /><br><br /><br>And there's a *huge* difference between mocking a component's interactions a web service and mocking a control's interactions with Windows.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-2441850399540300710.post-31952496810767038132006-02-08T08:21:00.000-08:002006-02-08T08:21:00.000-08:00Yeah, it is difficult to do TDD in some instances....Yeah, it is difficult to do TDD in some instances. But look at TypeMock.NET from http://www.typemock.com, it is a really good mocking framework. <br /><br><br /><br>I've posted a article the other day on how I solved an issue with a external Web Service depandency. Have a look at http://exceptionz.blogspot.com/2006/01/using-typemocknet-to-mock-external.html.<br /><br><br /><br>Cheers,<br /><br>MaruisAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-2441850399540300710.post-56417946333519558812005-01-11T01:33:00.000-08:002005-01-11T01:33:00.000-08:00That doesn't work when the interaction is comp...That doesn't work when the interaction is complex, with callback relationships and bi-directional message passing. <br /><br><br /><br>A control does not have a type relationship with Windows. It has a message-passing relationship. While that, too, could be mocked, it's a lot more complex...to the point of not being worth it. <br /><br><br /><br>As someone else pointed out, you can still be test driven in this case. Just not NUnit test driven.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-2441850399540300710.post-67962491182225963772004-10-25T13:39:00.000-07:002004-10-25T13:39:00.000-07:00I agree: you should adopt a test-first mentality a...I agree: you should adopt a test-first mentality and hold on to it whenever you can. However, as was pointed out above, you might be doing test-driven development without doing *automated unit test* driven development. Automated unit tests imply that you have to simulate your client/caller, which can be quite complex. Complex enough to stop you from doing it? Depends on your situation. <br /><br><br /><br>I should also point out that I didn't mean to imply in any way that developers are absolved from writing all the tests they can. Rather, that we should remember that enlisting the test team to write simulations and automation for more complex scenarios - since they have the tools and expertise to do it - is a good idea. It's just about division of labor, not passing the buck. <br /><br><br /><br>As widely available tools mature (e.g. NUnitAsp, NUnitForms), the cost of automation by the developer will continue to drop, and the test team can shift their focus to even more complex scenarios.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-2441850399540300710.post-1045924483510771422004-10-25T07:37:00.000-07:002004-10-25T07:37:00.000-07:00I've written something similar for my clients,...I've written something similar for my clients, but rather than parsing code, I use FxCop to check properties of my assemblies. It seems to be a bit more flexible, as well as being language neutral. Plus FxCop brings so much other goodness to the table.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-2441850399540300710.post-17962186462811295372004-10-25T06:55:00.000-07:002004-10-25T06:55:00.000-07:00I've started reading the text of my program as...I've started reading the text of my program as a test. I check to see that I have made specific connections to framework elements by ensuring that specific interfaces have been coded.<br /><br><br /><br>Then I can keep my state testing within the model. I use an MVC pattern and pass the "container" interface into the model. The code-checking tests verify that the controller has been set up to the view, and that the view is effectively connected (by code) to the the framework.<br /><br><br /><br>I call these tests "Verifiers".Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-2441850399540300710.post-75246732383119095742004-10-24T12:44:00.000-07:002004-10-24T12:44:00.000-07:00I think Jens nailed it when he pointed out that th...I think Jens nailed it when he pointed out that there's a distinction between developer-written test, and test team-written tests. I think it's pretty well recognized that both are useful tools in developing quality software. Long-running tests are probably the domain of the test team, rather than the developers, as adding "two hours" to every developer build is not feasible. <br /><br><br /><br>State machine development seems to my inexperienced eyes to be a tool primarily useful for the test team, with the impact to the dev team being *perhaps* to modify their code to make it easier for the test team to inspect application state. <br /><br><br /><br>In other words, it sounds like a great approach as part of the overall process, but I don't think it's going to change the way I code.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-2441850399540300710.post-13954423654410425172004-10-24T08:56:00.000-07:002004-10-24T08:56:00.000-07:00The assertion is a bit extreme I admit it :).
Bu...The assertion is a bit extreme I admit it :). <br /><br><br /><br>But imagine that you want to hit the long-run tests, the ones that appear after using 2hours an application or with a sick combination of key strokes. Ideally, you would build a state machine and let run until it crashes (or not).Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-2441850399540300710.post-90406874040483703332004-10-24T05:28:00.000-07:002004-10-24T05:28:00.000-07:00Hmm. I've written fully tested GUIs without ex...Hmm. I've written fully tested GUIs without explicitly generating a state machine, so I'm not sure I buy your assertion. <br /><br><br /><br>The article is interesting, however, and clearly a model-drive approach would be useful when the application lends itself to it.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-2441850399540300710.post-51963914755866817352004-10-22T03:45:00.000-07:002004-10-22T03:45:00.000-07:00I use mock objects extensively, so I know how usef...I use mock objects extensively, so I know how useful they can be. However, when what you're trying to mock up is the Windows Operating System itself...mock object solutions aren't particuarly helpful.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-2441850399540300710.post-1926295216211173482004-10-19T17:09:00.000-07:002004-10-19T17:09:00.000-07:00Sure - when the container is amenable to automatio...Sure - when the container is amenable to automation, that can be a handy approach. But as you observe, sometimes it isn't.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-2441850399540300710.post-49630773578226766202004-10-19T11:34:00.000-07:002004-10-19T11:34:00.000-07:00If the container is that difficult to simulate, wh...If the container is that difficult to simulate, why not use the real thing? Have your testing code load your control in a WinForm and play with it (causing events and calling methods to verify that everything stays consistent).<br /><br><br /><br>Obviously, that doesn't allow you to test whether the control sends the right events to its host control but at least you can get pretty extensive test coverage on your own code without tripping on your inevitably imperfect fake host. I say that's better than nothing.<br /><br><br /><br>I agree with you, when the container is complex it becomes very labor-intensive to test your component. Extreme example: my boss actually wants us to implement the entire MAPI specification in order to test our MAPI component (a MAPI Message Store Provider). Please don't laugh.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-2441850399540300710.post-19923027886853970182004-10-18T02:47:00.000-07:002004-10-18T02:47:00.000-07:00I think that's a great idea. One of the main r...I think that's a great idea. One of the main reasons I didn't go this route was that when I started that particular project, I was just playing around. I could have gone back and retrofitted it, but I was lazy. :) <br /><br><br /><br>In any event, I still believe that there are cases where container-component interaction is so complex that any sort of TDD will start to get very expensive. For example, trying to test logic that ensures a particular piece of text got drawn at x, y location 25, 168 and has a red wavy underline with a solid, one-pixel border might get a little hairy. It's not that it can't be done, it's that it starts to be a net-zero or net-loss proposition. <br /><br><br /><br>But as I said, I still believe in testing as much as you can. You seem to have found a way to automate testing of a large part of your app, which is a good thing.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-2441850399540300710.post-77826371415382775822004-10-17T23:58:00.000-07:002004-10-17T23:58:00.000-07:00I think you hit the nail on the head when you ment...I think you hit the nail on the head when you mentioned other ways of testing - after all, it is TDD not UTDD (unit test driven development).<br /><br><br /><br>One approach I started to use in my previous project was to have lots of ASSERTs, a debug/trace listener that I could query against, and use a record/playback technique (in my case the John Robbins "Tester" utility that was presented over the course of a number of BugSlayer articles). The nominal case is tested by running and checking the specialised log listener recorded no errors or warnings, then as you go along you can test for error conditions by recording appropriate usage, then adding playback and checking into the test script.<br /><br><br /><br>This is clearly not unit testing (system? smoke? integration?), but I'd still say the development was test-driven.<br /><br>Anonymousnoreply@blogger.com