Summary
When testing UI controls, automated unit testing is usually not practical. Why? Because to verify if a UI control is working correctly, you generally have to look at the screen and see if it looks right. Looking at the screen often entails more than just checking that the various fields have the right data. Often there are interactions between the controls, focus issues, or painting artifacts that a human can detect more easily than a mindless unit-testing program. Don’t get me wrong: Automated unit testing with systems like NUnit and JUnit is definitely advisable for code that doesn’t have a user interface.
You can download SystemBrowser’s complete source code from the Source Code area of the Apress Web site (www.apress.com).
This is a preview of subscription content, log in via an institution.
Buying options
Tax calculation will be finalised at checkout
Purchases are for personal use only
Learn about institutional subscriptionsPreview
Unable to display preview. Download preview PDF.
Rights and permissions
Copyright information
© 2006 Ted Faison
About this chapter
Cite this chapter
(2006). Case Study 1: A System Browser. In: Event-Based Programming. Apress. https://doi.org/10.1007/978-1-4302-0156-4_11
Download citation
DOI: https://doi.org/10.1007/978-1-4302-0156-4_11
Publisher Name: Apress
Print ISBN: 978-1-59059-643-2
Online ISBN: 978-1-4302-0156-4
eBook Packages: Professional and Applied ComputingApress Access BooksProfessional and Applied Computing (R0)