We present an approach for assertion-based random testing of Prolog programs that is tightly integrated within an overall assertionbased program development scheme. Our starting point is the Ciao model, a framework that unifies unit testing and run-time verification, as well as static verification and static debugging, using a common assertion language. Properties which cannot be verified statically are checked dynamically. In this context, the idea of generating random test values from assertion preconditions emerges naturally since these preconditions are conjunctions of literals, and the corresponding predicates can in principle be used as generators. Our tool generates valid inputs from the properties that appear in the assertions shared with other parts of the model, and the run time-check instrumentation of the Ciao framework is used to perform a wide variety of checks. This integration also facilitates the combination with static analysis. The generation process is based on running standard predicates under non-standard (random) search rules. Generation can be fully automatic but can also be guided or defined specifically by the user. We propose methods for supporting (C)LP-specific properties, including combinations of shape-based (regular) types and variable sharing and instantiation, and we also provide some ideas for shrinking for these properties. We also provide a case study applying the tool to the verification and checking of the code of some of the abstract domains used by the Ciao system. Research partially funded by MINECO TIN2015-67522-C3-1-R TRACES project, and the Madrid P2018/TCS-4339 BLOQUES-CM program. We are also grateful to the anonymous reviewers for their useful comments. At run time, sorted(Ys) will be called within the assertion checking-harness, right after calls to qs/2. This harness ensures that the variable bindings (or constraints) and the whole checking process are kept isolated from the normal execution of the program (this can be seen conceptually as including a Prolog copy_term, or calling within a double negation, \+\+, executing in a separate process, etc.). Testing vs. Run-Time Checking: The checking of sorted/1 in the example above will occur in principle during execution of the program, i.e., in deployment. However, in many cases it is not desirable to wait until then to detect errors. This is the case for example if errors can be catastrophic or perhaps if there is interest in testing, perhaps for debugging purposes, more general properties that have not been formally proved and whose main statements are not directly part of the program (and thus, will never be executed), such as, e.g.: