Customize Progress Report screen in testing? (DevOps) - testing

In the progress report in the testing module, the "Run %" includes things like "Paused", "Blocked" and "Not applicable". Is there a way to fine tune the Progress Report screen to exclude those from what's counted as being run?
Additionally, is there a way to add custom test outcomes?

Related

Microsoft Access - Progress bar when running a single query

I've seen a number threads / forums with examples of progress bars in access databases which unfortunately hasn't resolved my issue.
I know Access has a small status bar that shows you the progress of the running query but this is not adequate for my needs.
Is it possible to show on a popup form a progress bar of the current (single) query that is running? displaying the percentage of how much of the query has been processed?
or perhaps would it be possible to display the status bar in a popup form?
Many thanks
Max
No, you can't do either.
For a single query, all there is is the internal, automatic progress bar.
Custom, manual progress bars are only possible if you have multiple actions (like a loop).

How to show run tool only when there is an error in IntelliJ Idea?

I use TDD quite a lot, and I was wondering if there is a way to show the Run Tool window only when there are failed tests?
Or to be more generic, for any run configuration, I would like the Run Tool window to be shown only when something goes wrong. Otherwise I would prefer the little non-obtrusive green pop-up to appear. Like when you run a lot of tests and you minimize the Run Tool by clicking on the "down arrow" in its top-right corner. When the tests are done, a little green pop-up appears over the minimized window.
I would also compromise for an answer that tells me how to keep the Run Tool always minimized, and only see little pop-ups, regardless if they are green or red.
This is probably not exactly the answer you wanted but if you look in the RunConfiguration (Run->Edit Configurations -> JUnit) for your test run you should see a checkbox called 'Activate tool window'. If that box is ticked then the Run Tool window will pop open even if its minimised. When it's not ticked then the Run Tool window will stay minimised.
So, for any individual existing test run you can change the check box value to prevent the tool window appearing. If you're doing TDD that could mean you have many configurations for specific test cases / suites etc, which you would need to change individually.
In the longer term, you probably want to avoid future run configurations popping up the test. You can do that through the Defaults -> JUnit section in the RunConfigurations window.
Also, in the tab "Logs" you can check the option "Show console when a message is printed to standard error stream"
When this option is checked the window is opened automatically if some test fails.

Funcunit - why does the speed and reliability of my tests differ depending on whether the test is being run in the active tab in Chrome?

I'm trying out FuncUnit with a simple login/logout script for an app, using Chrome on Windows 7. I've noticed that both the speed and reliability of the test differ depending on if the test is running in the currently selected tab in Chrome.
If the tab isn't selected, the test runs quickly and without error. If the tab is selected, text is typed slowly and sometimes incompletely (so only half the password will be typed before the submit button is clicked), clearly visible elements fail to be found and the test has about a 50% success rate.
Am I missing something here? It's proving less reliable than even QTP unless I deliberately deselect the loaded tab and I'm dubious about any automated test that needs user interaction to pass reliably.
Turned out to be a Chrome version specific issue

Is there any way to write debug output to Android Studio in design mode?

When the output in design mode is not as expected in Android Studio, is there anyway to debug this by for instance inserting log-writing code that will be visible in the Android Studio IDE?
Let's say you're coding a custom View which will render a triangle. The designer renders a blank view. You want to inspect the variables at a certain point in the onDraw-method. The only way I've found is to insert a throw new RuntimeException("X is: " +x). This produces an exception which is visible in the designer, but it's not a good solution.
Is it possible to insert any smoother code which doesn't terminate the execution and still allows you to inspect the data?
I'm not sure of how to do this in design mode, but you could set up a quick test of the view to do this while running.
Android Studio provides a real-time logcat view for connected devices - just click the Android label at the bottom of the IDE.
You can use the logcat to monitor any output you specify using the Android Log object's methods.
It might be a good idea to use a custom tag for your log entries and then filter the logcat to only display entries with that tag, for example:
Log.v( "SomeLabel", "X is: " +x );
If you filter the output to SomeLabel in this example, you will only see the entries you want.
Also, if your onDraw method runs in real-time, it might be a good idea to only log once per second (or at some desired interval), instead of every call.

Programmatically open detail section of progress dialog in Eclipse

In a progress dialog (IProgressMonitor), there is a Details button that expands the progress dialog to show the details section. How do I open the details section programmatically in my Eclipse plugin?
Thanks.
You don't.
The UI for progress reporting is absolutely not part of the progress API, instead only the concept of tasks, sub tasks and their running state is part of that API. So in another version of eclipse the progress might be shown by playing a sound instead of showing a dialog.
Even your assumption of having that dialog is wrong. When you activate the workspace preference "Always in background", then a user will not see that dialog at all.
And as a last thing: Even if you feel that your plugin is so important that it should behave different than other plugins in Eclipse (and therefore want to access that progress dialog somehow), your users will not feel the same. And they will be confused when installing your plugin together with other plugins because they don't behave the same, although being part of one installation.