==== Full Test System ====
To reproduce the problem with {{UBIK}}, you require a test setup. This usually means creating a local copy of the affected database the problem occurred with , and an installation of installing the {{UBIK}} products relevant for the problem. It is important to use the same binaries, plugins and versions as in the system where the problem occurred.
Then, we can try to provoke the reported issue in the test setup. This might require getting more information about the issue.
[[Category:Best Practices (internal)|Debug a Customizing]]
[[Category:FAQ|Debugging UBIK]]
[[Category:How-To|Debugging UBIK]]
[[Category:Resources (internal)|Debug a Customizing]]
==== Isolation Testing ====
With Who-Bert code and manually created test data, you can additionally set up a "mock" or "fake" situation, to test the behavior under very specific circumstances.
The View Test Tool simulates how the web service assembles data for the client, ignoring the ACM meta definitions (context, scopes etc.).
Another way to isolation-test your Plugin code is writing [https://en.wikipedia.org/wiki/Unit_testing unit tests], which is strongly encouraged.
[[Category:Best Practices (internal)|Debug a Customizing]]
[[Category:FAQ|Debugging UBIK]]
[[Category:How-To|Debugging UBIK]]
[[Category:Resources (internal)|Debug a Customizing]]
= Inspection =
= Hypothesizing =
In order to narrow down the cause of the problem, we can try to formulate an idea of what could have gone wrong. Optimally, we actually go and look for a proof, to see it happen in action, but it's always good to know potential error sources. In general, there are several common types of problems, and from another perspective, a set of common sources for such problems.
=== Visualizing the architecture and algorithm ===
The user has to perform a few additional navigation steps, but on the other hand, they have to make that choice anyway.
We even help them selecting a pair of shoes by leading them through the right choices.
As a nice side-effect, the result consists of much fewer shoes , so it's computationally cheaper to load all the videos.Optimally, the parameters for the filtering can be inferred even without the user inputting them explicitelyexplicitly, e.g., by looking at the wheather weather and the user's calendar (sunny wheatherweather, hiking trip: probably not the rain boots).
Anyway, in some cases the use-case can be rearranged so the amount of data and information presented to the user at one point in time is smaller.