I forgot to comment about creating a new user: This is the difference between "the test needs root privileges and is even more invasive to the system" and "the test can run with normal user privileges and does not leave permanent clutter behind". I. e. creating a new user introduces the obligation to ensure that it always gets removed again, even if the test or test runner fails in the middle of the run.
Also, doing so doesn't actually help at all with the main issue here to centralize the knowledge how to start an UAL session: We need to do that regardless of whether this happens for a "real" user with a temp $HOME or for a temp user. So in summary, creating temp users only makes the test bed setup more complicated, less convenient, and potentially harmful (due to requiring root privs) without gaining much. -- You received this bug notification because you are a member of Unity API bugs, which is subscribed to Ubuntu Application Launcher. https://bugs.launchpad.net/bugs/1376423 Title: Provide script to set up a temporary user session Status in Ubuntu Application Launcher: New Bug description: For manual and automated testing we generally need to be able to start the applications in a clean environment, in a way that the tests are not affected by existing files and configurations. And as the tests should be easily runnable on the devs development machines, the changes made while running the tests should not affect the real environment. In the past we were able to get a reasonably clean environment setting the value of $HOME to a temporary directory. Now this is not enough by a variety of reasons, like a hierarchy of dirs in HOME needed by app armor, apps being launched by upstart, and services that keep listening to the previous value of HOME. Every test suite has solved this on it's own why, some use the real environment but backup the existing files (which is really bad), some patch the HOME and keep adding details every time something changes, and some others just pollute the real environment and can't be run on a dev machine. This is what has been causing failures on the majority of autopilot tests for the last month. Instead of keep doing these multiple solutions, and keep adjusting them every time they stop working; I think we need to find one single way that works for all the apps. And we need to add automated tests for this single way to make sure that no new releases will break it. I'm currently thinking of a testability helper in ubuntu-app-launch that we call to launch an app and it will make sure that it will start all the needed XDG vars pointing to a clean temporary environment. We might still need to restart some services, and we might hit some other problems, but this is just an idea. Feel free to propose alternatives. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-app-launch/+bug/1376423/+subscriptions -- Mailing list: https://launchpad.net/~unity-api-bugs Post to : unity-api-bugs@lists.launchpad.net Unsubscribe : https://launchpad.net/~unity-api-bugs More help : https://help.launchpad.net/ListHelp
