# '''Retest''': Test the fix
== Debugging a {{UBIK}} project ==
<!-- DO NOT REMOVE THIS -->{{Template:HowTo/Begin}}<!-- DO NOT REMOVE THIS -->
= Reproduction =
==== 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 ===
=== Leverage strengths ===
Usually, he the server is strong and fast, the mobile device not so much, and the network is a performance graveyard.
If you want to waste as much performance and time as possible, then you try to maximize the amount of network interactions and shift all the workload to the client application.
Vice-versa, leveraging the strengths in {{UBIK}} means to shift all the calculation and preparation to the server and deliver the results in a most compact way to the client in one request-response cycle.
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.
[[Category:Best Practices (internal)|Debug a Customizing]]
[[Category:FAQ|Debugging UBIK]]
[[Category:How-To|Debugging UBIK]]
[[Category:Resources (internal)|Debug a Customizing]]