-
Notifications
You must be signed in to change notification settings - Fork 0
Home
(Note: I here use "application" and "program" interchangeably, and also "UI"/"UX" and "unit-test"/"test")
The way to be assured of your forward progress on a software project is by running tests. Specifically, fully-automated unit-tests.
To be effective, these tests should confirm every bit of your application's functionality that is important to it's success. That is - everything that is listed in your Requirements document. To be efficient, each unit-test should, ideally, test one thing. This way you can identify quickly what is not working simply by which unit-test stopped working.
To work as planned, these tests should be easy to run, and ideally should run automatically. "Automatically" in the sense that
- There are no manual setup steps required. The unit-tests do their own setup and tear-down.
- They are executed automatically everyday, or even with each check-in of the source-code.
If certain of the unit-tests require manual effort to setup and run, then it will inevitably happen that someone will put it off. If this cannot be avoided, then separate your unit-tests into categories: the lightweight, automatic tests, and those which need to be manually run.
There is a further consideration - one which especially arises in the context of automated unit-tests: these should be kept to the minimum that you need to guarantee the functionality works. And not more. Otherwise, your testing regime is adding further burden to your team, and dragging you downward. Test to crucial functionality, not for implementation details (with exceptions - to be covered in a blog article).
And this brings us to UI (User-Interface) tests. Historically these are done manually, and can be quite tedious. It is not rare that this effort burns up the bulk of a project's testing resources. Why? Because it's harder to automate.
The objective of VisuTest, is to simplify your DevOps work by enabling more comprehensive UX unit-test design. It does not just improve UI testing - it makes it possible. To my knowledge there is no other solution for this problem-space.
The VisuTest library expands your unit-testing capabilities to include real UX confirmation.
This does not rely upon walking the JavaScript DOM to confirm properties. It launches the UI of your application, looks at the screen, and confirms that a thing is present or that it's appearance is correct. It simulates the user clicking upon controls, making selections, entering text, hitting keyboard-keys.. you get the picture. VisuTest does what your test personnel have had to be doing up to this point. And the challenge has been to provide essentially the same intelligence in discerning pass from no-pass, that a human end-user employs.
- Confirm that, upon launching the program - the UI does in fact appear.
- Confirm that there are no error messages being shown.
- Test that a given widget (text label, text entry field, button, dropdown-list, image) is present.
- Confirm that the text of a field expresses it's content correctly. (this includes the semantic and syntactical aspect of the text, the language/culture, and aesthetic aspects)
- See whether a given field or widget is incorrectly occluded by some other thing.
- Judge the spacial sense of a UI: are the labels close enough to their widgets, do columns line up, etc.
- When an error-message is shown, does it say what it needs to say? Confirm this without over-specifying the text.
- After a user-interaction, how long does it take before your program reacts to it?
WHAT ELSE DO YOU NEED TO BE TESTED FOR?
Exclusion: If your UX includes a custom control with behavior or appearance that does not match any of the standard categories of widget - you're on your own.
This is currently realized as a suite of tools and code-libraries targeted toward the Windows and Linux desktop platforms and for online projects (MacOS will have to wait until I get an iMac back on my desk). The source-code libraries primarily target these programming languages: JavaScript, Java, C#, and F#. Swift will come a bit later.
To execute the UI tests, the kit and instructions speak to the use of virtual machines (VMware, Microsoft Hyper-V) and containers. You know ya gotta.
This is a work-in-progress at this point and not yet ready for deployment. What is called for right now, is YOUR input. What would you like to see provided. What sort of integration strategy works for you. Etc.
The initial cut desktop-application source-code and the library binaries are undergoing a rework at this moment (as of 2020-01-30) and are scheduled to be uploaded on March 15th for an alpha-status version. The initial language is English only, and the tested platforms are initially going to be one of: the .NET Framework on Windows 10 implemented in WPF, Winforms, and UWP, and HTML/Javascript applications.
James W. Hurst