Have you ever had that itch you just can’t seem to ever get rid of despite all your scratching? Well, UI Testing is that same itch for many developers. Fortunately, Coded UI Test exists, allowing us to scratch that itch with ease and relieve the heartache that is UI Testing.
A very important part of our development process is testing our software to ensure that each product is the best it can possibly be for our customers. There can often be a lot to test in a short period. Having a fast, efficient, repeatable, and reliable way to make sure everything is tested is what we strive for. Coded UI Test (CUIT) allows us these attributes.
CUIT creates automated tests used for functionality testing of a GUI application. There are several ways to go about this, the first being the ‘Record and Playback’ feature that CUIT provides. This option allows us to set up tests by starting the recording feature and performing the tasks the developer would like to test. The recording feature will record everything the developer does and automatically generate a test for us. After it is generated we can play it back to run the test as many times as we want.
The recording feature alone is not the only option CUIT provides of course. However, the recording feature certainly does help when writing our own scripts when we want to go beyond the basic testing features available through the recording. Since the recording feature generates its own C# code, we can use those generated scripts to see how the CUIT works and expand on those scripts to fit our needs.
We can see in this generated code snippet how CUIT goes about looking for a button in a WinForms application. This button in the above sample is named ‘Refresh’ and once CUIT finds this button through this code snippet, we can do many different things with the button. This includes clicking the button, verifying the test in the button, seeing whether the button is disabled or not, and many other things we might want to check in our tests. Now with this code snippet in mind we can modify it to look for other buttons or other controls such as checkboxes, radio buttons, and other controls we might want to include in a test.
We want to be able to expand upon our tests through the help of our Software Engineers and not just our Quality Engineers. Thankfully, CUIT uses C# instead of a proprietary scripting language, making it easy for our Software Engineers to go from working on our applications to writing tests through CUIT for our applications. This enables us to collaborate effectively and make sure our products are being tested as best they can.
CUIT is a great way to develop sophisticated tests for our applications to assure our customers will be satisfied with our products. We will continue to create more tests within CUIT to help us make sure no new bugs are introduced. The more tests we can automate through CUIT, the faster and more efficient our testing process will be and the easier it will be for us to identify potential problems if they arise, helping us create a product we can continue to be proud of.
