开云体育

The general rule we have is to test the model and the controls that dictate the changes to the UI, but the UI itself can't be tested with unit tests. Alternatively, you can try to take screen shots and try to do jpg comparisons (but I don't recommend it) brought to you by the letters A, V, and I and the number 47

I ran across this the other day... Microsoft UI Automation library "In this month's column, I will show you how to get started with UI test automation using the new Microsoft UI Automation library, which is included in the .NET Framework 3.0 as part of Windows Presentation Foundation (WPF)." http://msdn.microsoft.com/en-us/magazine/cc163288.aspx -- Bill Arnette

I found pex useful for teaching the concept

Hi, I was wondering how I would go about finding TDD's in C# for my company. Any suggestions would be greatly appreciated. Kind regards, E

I'm kind of new to WPF and trying to TDD an application that uses it. I'm a little frustrated that Microsoft's default program architecture still isn't TDD friendly. It creates an application project and adds a window and an app level resource dictionary, none of which can be tested because a test system requires a DLL it can load. But if I create a new DLL, it loses connection to the base resources because that's in the exe and not available in testing. So the architecture seems wrong, and I don't know what's a more ideal way to proceed. Or, is there something I'm missing about testing UI code. Alan Baljeu

Alan, When I was last working on an app with WPF I was trying to test the GUI layer by doing things like “press button” and verifying that the presenters got events. I seem to remember that I had to add some methods to actually allow pressing buttons and selecting list items and so on – but it was simple enough and worked well enough for me to feel confident. Of course, I was also running the whole thing to see that it was making visual sense. I think it may be goodness to keep away from testing for visual aspects (your example of a medium-complex double list control…). That way it’s easy to change the look-and-feel while still leaving the functionality. So: - Just handle the events emitted from the GUI. - Make sure the GUI handles its responsibilities. - Inspect the GUI. John D.

I haven't done much with WPF for a couple of years but you can use MVVM and unit test the subcutaneous layer or you can use an automation tool like White http://www.codeproject.com/Articles/289028/White-An-UI-Automation-tool-for-windows-applicatio

It's mostly on the XP list, and that quite by accident. What happened is that the original XP had all of the pieces, but they were just that: pieces. You put them together and the software construction process just flowed. Then several people noticed that the pieces that are part of TDD actually linked together tightly, and formed something where the sum was greater than the parts. I know that's a hackneyed phrase, but sometimes it's quite appropriate, and this is one of them. Kent named it TDD and wrote a book about it. The rest is history. The pieces in TDD go back a long ways. Kent's genius in Simple Design wasn't creating a new design method, it was in throwing everything else out. Refactoring, for example, is probably the newest of the pieces and it wasn't exactly new when XP, let alone TDD, was created. However, people who just refactor sometimes get into states where they flounder around. Simple Design gives a goal: if it doesn't either remove duplication, increase expressivity or simplify some piece of code (make it smaller) it's not worth doing. And if it breaks tests, it's wrong. John Roth

On Monday, October 28, Agile Denver will host guest speaker Stephan Hagemann. Stephan will present on the Go language (golang). Go was invented at Google and includes enhancements that can make it more productive for Agile teams, such as increased testability. Stephan will provide a brief introduction to Go from an Agile programmer's perspective, explore Go's testability in some depth, and then compare an Go in the Agile context to other common languages like Java and C/C++. Stephan is an Engineering Manager at Pivotal Labs in Boulder. For most of his days that means writing software. Currently he contributes to the Cloud Foundry PAAS by helping develop its user logging infrastructure, which is entirely written in Go. With every project he especially enjoys the continuous search for doing the right thing, and doing that right. Please see http://agiledenver.ning.com/events/agile-denver-201310 for more information.

Eb, Generally speaking, I do not check arguments for correctness. If I am building the entire app via TDD, the code that calls the method is already tested, and therefore in fact calls with correct arguments. If the method in question is potentially harmful, then I will be more inclined to cause it to protect itself, and I would generally test that. This approach generally works for me. My experience is that "defensive" code generally makes the program much larger, increases its complexity, and since the defensive code is both arcane and hard to test, it usually embodies a disproportionate number of defects. So I focus on writing correct code, not code that lives in fear of its neighbors. Ron Jeffries www.XProgramming.com I have two cats, and a big house full of cat stuff. The cats fight and divide up the house, messing up their own lives. Nice work cats. Meow.

Where does that data come from? Programmers or external sources? Development time or runtime? I don't test against programmers but might test if data comes from a file or database. Humans can figure out when they're wrong, especially if they write tests. Of course I worry a bit more if the parameters are not type-safe and/or the ordering of parameters is not obvious and natural. So that leaves the last question as whether the interface invited advise.

IIRC, the terms London and Detroit school were dreamt up on this list as a reaction to the negative reactions to "mockist/statist" terminology. Can't remember who suggested them, but they stuck at least for a while. The reason the top down mock based approach is called London school is that Steve and Nat wrote about it and they live in London. The reason the other approach is called Detroit school is Ron and some of the other early XP guys live in the vicinity.

Hi David, In fact I generally work "outside-in", with occasional experiments on "I wonder whether, if I took this course, I could make such and so happen", where I'll build some inside thing. I would save that thing for reference, perhaps, but would not expect to use it as is. The experiment would be to teach me what's possible and a bit about how to do it. Then I'd let my usage of the thing tell me what it wants to be. And either direction, parameter checking would be rare. As would mocks, being as I'm Detroit School and all. Ron Jeffries www.XProgramming.com If it is more than you need, it is waste. -- Andy Seidl

I will be honest. Except for the most basic of VOs I don't know how you can be sure of what is 'inside' and what is 'outside'. Sometimes even your GUI becomes a component for a wrapper.

Hello everyone - I'm curious to know thoughts on writing tests that specify the behavior of a method when its inputs are incorrect. Is this a common practice. How about parameter validation in this case? Having some healthy debate on it and wanted to get other insight. The context for this in a class/methods that are used within an internal application - this is not an API that will be publicly exposed to external consumers. Thanks. -- blog: http://eikonne.wordpress.com twitter: @eikonne

If this is internal code only and the code calling it is also testing then I not only would I not test it but I'd remove all defensive code guards as well. For example, a typical pattern would be: public void foo(SomeObject bar) { if (bar == null) { ..... } } Instead of catching the null and handling it, ensure all code calling it will never pass in null. Cuts down on both test and production code. -- Maybe she awoke to see the roommate's boyfriend swinging from the chandelier wearing a boar's head. Something which you, I, and everyone else would call "Tuesday", of course.

It depends on the language, but in general, I think it should be tested. brought to you by the letters A, V, and I and the number 47

Although there are an abundance of unit testing frameworks for C++ out there, I decided to learn some of the features available in C++11 by writing yet another one. At this point it's mostly for play and to scratch an itch. I wanted to bring the good parts of writing unit tests in other environments with a quick setup, readable tests, no hardwiring to a specific assertion framework, and ease of organizing test hierarchies so that setups for a context can be easily reused and augmented by sub contexts. Anyway, there's a lot of subjectivity here, but if you find this interesting please take a look and let me know what you think. https://github.com/joakimkarlsson/bandit / Joakim

Eb, I wouldn't do that. I use adapters for third-party collaborators and mock my adapters to verify behavior. I also write integration tests for the adapter's interaction with the third-party. Steve Freeman's advice is to never mock something you don't own. I've only violated that advice when I needed to simulate error conditions while testing my adapter. - George -- Want to speak at AgileDC October 8, 2013? http://agiledc.org/speak/ ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ----------------------------------------------------------------------

Hi everyone - What criteria do you use to determine if a collaborator that is a third-party should be mocked and the test should verify that the collaborator was indeed called when it was supposed to be? Thanks. Eb -- blog: http://eikonne.wordpress.com twitter: @eikonne