One theory of testing Ansible playbooks: keep adding tasks doing things you want. Think of it as asserting the desired state. Good modules will fail early and loudly if they cannot accomplish a task.
Say you are nice to your interactive users and want to provide tmux and Midnight Commander. Add those to a list of packages
# in some vars file
packages:
- mc
- tmux
... with an install task.
# in some role's tasks file
- name: Install software for thing
package:
state: present
name: "{{ packages }}"
Add to the package list when you want to install more things. What if something to install is from a third-party repository not yet available? Before your package task, add tasks to install the repo. And take the opportunity to configure automatic updates, if applicable.
Do all customization within your automation. Template out config files. Enable and start services. Map users to their ssh public keys and get rid of passwords. Display an informative banner on login. Whatever else you want to do.
Maintain a test user with the same reduced privilege as the rest of your users. Test ssh to it works by using its credentials (ansible_user and ansible_ssh_private_key_file) and running a basic task.
Some things you want to check aren't necessarily module failures. Modify how tasks fail when a failed_when: expression where necessary. Add assert: tasks that check arbitrary conditions on variables.
When playbooks are run against a fleet of hosts, the problem ones will be apparent because they failed.
Ansible is a scripting language tool. It remotes into hosts and runs Python or Powershell or whatever. GUIs are not its thing. Get some other tool if you want automated testing of actually launching a GUI and doing stuff.
Although, with how quickly and accurately you can configure hosts, you might not need a lot of automated test tools. When a host goes from base image to configured in minutes not hours, perhaps that frees up time for a quick manual sanity check prior to every "release" you do.
