--- title: "Testing GUIs and customer tests using FIT" url: "https://osherove.com/blog/2004/9/3/testing-guis-and-customer-tests-using-fit.md" canonical: "https://osherove.com/blog/2004/9/3/testing-guis-and-customer-tests-using-fit.html" published: "2004-09-03T07:31:00" updated: "2004-09-03T07:31:00" tags: [".Net Original", "Agile Related"] author: "Roy Osherove" description: "One of the things I have still not talked about in any of my talks is about testing GUIs. The reason is pretty simple: I don't really do that. I find that the amount of effort it takes to test a gui with NunitASP…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Testing GUIs and customer tests using FIT By Roy Osherove September 3, 2004 In [.Net Original](https://osherove.com/blog/category/net-original), [Agile Related](https://osherove.com/blog/category/agile-related) **Historical article** · Originally published September 3, 2004; technical details may be outdated. One of the things I have still not talked about in any of my talks is about testing GUIs. The reason is pretty simple: I don't really do that. I find that the amount of effort it takes to test a gui with [NunitASP](http://nunitasp.sourceforge.net/) (whichh just resleased a new vertion, BTW) or [NunitForms](http://nunitforms.sourceforge.net/) is much higher that it is to simply separate as much logic as possible from the UI layer and test that functionality. I do believe in a test-first fasion - but I'm also a realist. Its jsut too time consuming and the benefits I'd get from it are minimal. If I don't test the GUI, however, the ramifications are not that horrible and usually very easy to fix. One thing that I **do** want to get into is the whole issue of customer tests - [using the FIT framework](http://c2.com/cgi/wiki?FrameworkForIntegratedTest). It's a pretty awesome idea actually: You wrap your object model in a testable and simple object model wrapper which internally calls your real objects and contains various properties that return results. You then let the customer write their own tests against your custom objects, only they don't program against them they actually fill out HTML tables in which they specify the object they want to instantiate, the method they would like to trigger, and the expected results of that call. It very user friends (compared to coding, anyway..) and I can see this as something that could change the way we face the customer today before a major release. I still have a few problems with it though. Such as - when do you actually take the time to write that object model? Customer tests are supposed to be written as the application is written. they also arenot a replacement for unit tests, so when do we have time to write them? do I code up a new method to my object model each time I write a new unit test? where exactly in the coding chain do customer tests fit in? how much extra work are they? Is the amount of extra work justifiable? I'd love it if someone with real world experience in that are has some comments on this matter. ## More in .Net Original [All posts in .Net Original](https://osherove.com/blog/category/net-original) - Sep 3, 2004 ### [.Net Blogger geek meets Eric Rudder, asks questions, gets answers, is happy](https://osherove.com/blog/2004/9/3/net-blogger-geek-meets-eric-rudder-asks-questions-gets-answe.html) - Sep 3, 2004 ### [WilsonORMapper at version 3.0, and what's an OR mapper anyway?](https://osherove.com/blog/2004/9/3/wilsonormapper-at-version-30-and-whats-an-or-mapper-anyway.html) - Sep 1, 2004 ### [Sunday at the VB.Net users group: Software Architecture: Techniques, Methods, and Issues](https://osherove.com/blog/2004/9/1/sunday-at-the-vbnet-users-group-software-architecture-techni.html) - Aug 30, 2004 ### [Simple data binding simplified using \[BindToField\] and \[BindToValueList\]](https://osherove.com/blog/2004/8/30/simple-data-binding-simplified-using-bindtofield-and-bindtov.html) --- ## About the author **Roy Osherove**: Senior Solutions Architect at AWS working on AI for production and AI-driven development; author of The Art of Unit Testing and Elastic Leadership, with about 20 years of consulting and training on unit testing, TDD, team leadership and continuous delivery. ### Sites - [RobotPaper](https://robotpaper.ai/): This blog: AI patterns and anti-patterns, AI and coding agents, and engineering leadership. - [osherove.com](https://osherove.com): Roy's personal site. Author of The Art of Unit Testing and Elastic Leadership; consulting and training on unit testing, TDD, team leadership and continuous delivery, plus about 20 years of blog posts. - [The Art of Unit Testing](https://www.artofunittesting.com): The Art of Unit Testing, 3rd Edition (Manning): readable, maintainable, trustworthy unit tests, plus TDD workshops in C#, JavaScript, Java and Kotlin. - [5whys.com](https://www.5whys.com): Roy's writing on software team leadership: self-organizing teams, surviving chaos, learning mode and the Elastic Leadership model. - [Pipeline Driven](https://pipelinedriven.org): Continuous delivery and DevOps practices: build patterns, pipeline-friendly testing, DevOps metrics and enterprise DevOps. - [Elastic Leadership](https://www.elasticleadership.com): Elastic Leadership, Roy's framework for software team leaders (survival, learning and self-organizing modes). ### Social - X: https://x.com/royosherove - LinkedIn: https://www.linkedin.com/in/osherove/ ### Contact - Contact form: https://forms.gle/jQSx5KoXvrVA1JCK7 ### License Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page). License: https://creativecommons.org/licenses/by/4.0/