/
tests.html
47 lines (47 loc) · 26.7 KB
/
tests.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
<style type="text/css">@media screen { h1,h2,h3,h4,h5,p,a,br,li,td,.underline {font-family:sans-serif;text-align:justify} h1,h2,h3,h4,h5 {padding-bottom:.3em;border-bottom:#DDDDDD 1px solid} body {font-size:11pt;line-height:1.4em;max-width:1600px;padding:0em 2em 0em 2em;margin: 0 auto;} h1 {font-size:18pt;margin-left:0em} h2 {font-size:16pt;margin-left:0em} h3 {font-size:14pt;margin-left:0.5em} h4 {font-size:13pt;margin-left:1em} h5 {font-size:12pt;margin-left:2em} hr {text-align:center;height:1px;border:none;background:#CCCCCC} ol,ul,p,table {margin-left:3em;margin-right:3em;line-height:1.4em} a {text-decoration:none} a:hover {text-decoration:underline} img {display:block;max-width:100%;margin: 0 auto;} dl {border-left:1em solid #EEEEEE;padding-right:2em;font-family:sans-serif;display:grid;width: 80%;margin:1em auto 1em auto;grid-template-columns: max-content auto;column-gap: 1em;row-gap: 1em;} dt {white-space:nowrap;margin-left:1em;font-weight:bold;width:10em;} dd {text-align:justify;} .defword {width:25%} .defexplain {} .defexplain p {padding:0em;margin:0em} .deftablepara {} .deftable {width:85%;padding-left:1em;border:1px solid black;vertical-align:top} .deftable td {text-align:left;vertical-align:top} .deftablefaq {border-style:solid;border-width:thin} .stdtable {max-width:calc(100% - 6em);margin: 0 auto;border:1px solid;background:#CCCCCC} .stdtable th {padding:0.3em;background:#EEEEEE;font-family:sans-serif;font-weight:bold;text-align:center} .stdtable td {padding:0.3em;background:white;text-align:left;vertical-align:top} .end {font-size:8pt} .example {margin-left:3em;margin-right:3em;overflow-x:hidden;background-color:#F8F8F8;border:1px solid hsl(0, 0%, 90%);padding:1em} .header {margin-left:3em;margin-right:3em;background-color:#FFFFEE;border:1px solid hsl(0, 0%, 60%);padding:1em} .indented {margin-left:3em} .litable {text-align:left} .new {border-right:10px solid;padding-right:10px;font-family:sans-serif} .note {margin:0.5em 3em 0.5em 3em;background-color:#F0F0A0;border:1px solid hsl(60, 100%, 30%);padding:0em} .note .title {font-family:sans-serif;font-weight:bold;margin:0.5em} .note .message {margin:0.5em 1.5em 0.5em 1.5em;padding:0em} .note .message p {padding:0em;margin:1em 0em 1em 0em} .nobreak {white-space:nowrap;} .reference {} .inlinereference a {font-weight: bold;color:#448844;white-space:nowrap} .inlinesvg {width:1em;height:1em;vertical-align:middle;} .inlinedatatype {padding:0.1em 0.5em 0.1em 0.5em;border-radius:5px;border:solid 1px hsl(0, 100%, 75%);background:#FFCCCC;color:black} .caption {font-size:10pt;text-align:center;font-style:italic} .buttonpanel {margin:0em} .button {padding:0.5em;margin:0em} .buttoninactive {padding:0.5em;margin:0em;color:#AAAAAA} .inlinebutton {white-space:nowrap;padding:0.1em 0.5em 0.1em 0.5em;border-radius:5px;border:solid 1px hsl(120, 50%, 60%);background:#CCFFCC;color:black} .inlinekeyshortcut {white-space:nowrap;padding:0.1em 0.5em 0.1em 0.5em;border-radius:5px;border:solid 1px hsl(210, 50%, 30%);background:#0088CC;color:white} .inlinevalue {white-space:nowrap;font-family:monospace;white-space:pre;padding:0.1em 0.5em 0.1em 0.5em;border-radius:5px;border:solid 1px hsl(60, 100%, 40%);background:#FFFF66;color:black} .todolist {padding:0.5em;font-size:10pt} .todolist p {margin:0em 3em 0em 3em} .reviewlist {padding:0.5em;font-size:10pt} .reviewlist p {margin:0em 3em 0em 3em} .commentlist {padding:0.5em;font-size:10pt} .commentlist p {margin:0em 3em 0em 3em} .todo {margin:1em 3em 1em 3em;padding:0.5em;background:#FFAAAA;border:solid 2px hsl(0, 100%, 40%);font-size:10pt} .todo p {margin:0.2em 1em 0.2em 1em} .review {margin:1em 3em 1em 3em;padding:0.5em;background:#AACCFF;border:solid 2px hsl(210, 100%, 40%);font-size:10pt} .review p {margin:0.2em 1em 0.2em 1em} .comment {margin:1em 3em 1em 3em;padding:0.5em;background:#FFFF22;border:solid 2px hsl(60, 100%, 40%);font-size:10pt} .comment p {margin:0.2em 1em 0.2em 1em} .inline {margin:0.5em 3em 0.5em 3em;background-color:#EEEEEE;border:solid 1px hsl(0, 0%, 60%);padding:0em} .inline .title {font-family:sans-serif;font-weight:bold;margin:0.5em} .inline .elements {font-size:10pt;margin:0em 0em 0.5em 0em;padding:0em 1em 0em 1em} .inline .elements p {display:inline-table;margin:0.25em 0.5em 0.25em 0.5em} .tocindent {margin-left: 2em} .top {font-size:10pt;text-align:right} .topbutton {padding:0.5em 0em 0.5em 0em;} .underline {text-decoration:underline} #draft {font-family:sans-serif;position:fixed;bottom:0;max-width:1600px;width:100%;padding:.2em;background-color:#ff0000;color:#ffffff;font-weight:bold;text-align:center;z-index:9999;} } @media print { h1,h2,h3,h4,h5,p,a,br,li, #underline {font-family:sans-serif;text-align:justify;orphans:5;widows:5} p,li,td {font-size:10pt} ul,ol {page-break-after:avoid;orphans:5;widows:5} }</style><title>Test framework documentation</title><script src="https://ajax.googleapis.com/ajax/libs/jquery/1.9.0/jquery.min.js"></script><script>$(document).ready();</script><script type="text/javascript">window.MathJax = {AsciiMath: {decimal: ','}, asciimath2jax: {delimiters: [['`','`']]}};</script><script type="text/javascript" src="http://cdn.mathjax.org/mathjax/latest/MathJax.js?config=AM_HTMLorMML"></script></head><body><a id="top" name="top"></a><h2>Test framework documentation</h2><pre class="header"><strong>Author: Ladislav Mecir</strong></pre><hr /><h2>Contents</h2><div class="tocindent"><a href="#sect1"><strong>1. Introduction</strong></a><br /><a href="#sect2"><strong>2. Types of tests</strong></a><br /><a href="#sect3"><strong>3. How to run the tests?</strong></a><br /><a href="#sect4"><strong>4. Log file name</strong></a><br /><a href="#sect5"><strong>5. Summary</strong></a><br /><a href="#sect6"><strong>6. Log file contents</strong></a><br /><a href="#sect7"><strong>7. Filtering test logs</strong></a><br /><a href="#sect8"><strong>8. Comparing test logs</strong></a><br /><a href="#sect9"><strong>9. Features of the test dialect</strong></a><br /><a href="#sect10"><strong>10 Test dialect</strong></a><br /><div class="tocindent"><a href="#sect10.1"><strong>10.1 Test cases</strong></a><br /><a href="#sect10.2"><strong>10.2 Comments</strong></a><br /><a href="#sect10.3"><strong>10.3 Flags</strong></a><br /><a href="#sect10.4"><strong>10.4 Files/URLs</strong></a><br /><a href="#sect10.5"><strong>10.5 Example</strong></a><br /></div><a href="#sect11"><strong>11 How to contribute?</strong></a><br /><div class="tocindent"><a href="#sect11.1"><strong>11.1 The file containing tests</strong></a><br /><a href="#sect11.2"><strong>11.2 File format</strong></a><br /><a href="#sect11.3"><strong>11.3 Organization of tests</strong></a><br /><a href="#sect11.4"><strong>11.4 Checking new tests</strong></a><br /></div><a href="#sect12"><strong>12 How to run tests from Windows Explorer</strong></a><br /><div class="tocindent"><a href="#sect12.1"><strong>12.1 How to add a new association for Windows Explorer in Windows Vista, Windows 7, Windows 8, Windows 10 or Windows 11</strong></a><br /><div class="tocindent"><a href="#sect12.1.1">12.1.1 Possible interferences</a><br /></div></div><a href="#sect13"><strong>13 This documentation</strong></a><br /></div><h2><a id="sect1" name="sect1">1. Introduction</a></h2><p>This document describes the core test framework available at</p><p><a href="https://github.com/rebolsource/rebol-test">https://github.com/rebolsource/rebol-test</a></p><p>The test file format has been originally designed by Carl Sassenrath to be:</p><ul><li>Rebol compatible</li><li>as simple as possible</li></ul><div class="top"><span class="topbutton"><a href="#top">Back to Top</a></span></div><h2><a id="sect2" name="sect2">2. Types of tests</a></h2><p>This test framework supports unit testing of:</p><ul><li>Rebol interpreter (or compiler) core</li><li>Rebol function libraries</li></ul><p>GUI testing is not supported.</p><div class="top"><span class="topbutton"><a href="#top">Back to Top</a></span></div><h2><a id="sect3" name="sect3">3. How to run the tests?</a></h2><p>Example running core-tests in my machine with Microsoft Windows 11:</p><pre class="example">C:\Develop\rebol\rebview.exe -s run-recover.r</pre><p>My current local directory when running the tests is <strong>C:\Develop\rebol-test</strong>.</p><p>The test framework needs a path to the interpreter executable to be able to calculate interpreter checksum.</p><p>It is possible to give the <strong>run-recover.r</strong> script an argument. If the full path to the interpreter executable isn't obtained from the command line, the argument of the run-recover.r script, if given, is used as the path to the executable.</p><p>If the path to the executable is not available using any of the above methods, the test framework checksums to value of the <strong>system/build</strong> variable instead.</p><p>Example running core-tests in my Kubuntu machine:</p><pre class="example">ladislav@lkub64:/rebol-test$ /r3/make/r3 run-recover.r</pre><p>(my current local directory when running the tests is <strong>/rebol-test</strong>)</p><p>Don't worry when the program (either the test framework or the interpreter) crashes (in the core-tests suite there are some tests crashing the interpreter), just run the tests again the same way as before:</p><pre class="example">C:\Develop\rebol\rebview.exe -s run-recover.r</pre><p>or</p><pre class="example">ladislav@lkub64:/rebol-test$ /r3/make/r3 run-recover.r</pre><p>Until the testing finishes. After testing was finished, calling <strong>run-recover.r</strong> again does not do anything.</p><div class="top"><span class="topbutton"><a href="#top">Back to Top</a></span></div><h2><a id="sect4" name="sect4">4. Log file name</a></h2><p>The result of the test is a log file named like:</p><pre class="example">r_2_7_8_3_1_1DEF65_E85A1B.log</pre><p>(this is my <strong>run-recover.r</strong> result in Windows 8 running the official 2.7.8.3.1 interpreter) or</p><pre class="example">r_2_101_0_4_4_F9A855_E85A1B.log</pre><p>(this is my <strong>run-recover.r</strong> result in Kubuntu runnning my build of the 2.101.0.4.4 interpreter).</p><p>The first character of the log file name, #"r" is common to all run-recover log files. The next part describes the version of the interpreter, the following 6 characters are a part of the interpreter executable checksum, and the last 6 characters preceding the file extension are a part of the core-tests.r file checksum.</p><p>As you can notice from the checksums, I used the same version of the <strong>core-tests.r</strong> file in both examples.</p><div class="top"><span class="topbutton"><a href="#top">Back to Top</a></span></div><h2><a id="sect5" name="sect5">5. Summary</a></h2><p>The summary (can be found at the end of the log file) I obtained was:</p><pre class="example">system/version: 2.7.8.3.1
interpreter-checksum: #{1DEF65DDE53AB24C122DA6C76646A36D7D910790}
test-checksum: #{E85A1B2945437E38E7654B9904937821C8F2FA92}
Total: 4598
Succeeded: 3496
Test-failures: 156
Crashes: 7
Dialect-failures: 0
Skipped: 939</pre><p>in the former case and</p><pre class="example">system/version: 2.101.0.4.4
interpreter-checksum: #{F9A855727FE738149B8E769C37A542D4E4C8FF82}
test-checksum: #{E85A1B2945437E38E7654B9904937821C8F2FA92}
Total: 4598
Succeeded: 4136
Test-failures: 142
Crashes: 15
Dialect-failures: 0
Skipped: 305</pre><p>in the latter.</p><p>As you can see, the test-checksums and the total number of the tests are equal. That is because we used the same version of the tests.</p><p>However, the numbers of succeeded tests, failed tests, crashing tests and skipped tests differ.</p><p>The reason why the number of skipped tests differ is that 2.7.8 is R2 while 2.101.0 is R3. These interpreter versions are different in many aspects and it does not make sense to perform some R2 tests in R3 environment and vice versa, which leads to the necessity to skip some tests depending on the interpreter type.</p><p>The "Dialect failures" number counts the cases when the test framework found incorrectnesses in the test file, cases when the test file was not written in accordance with the formatting rules described below.</p><p>If you get more than zero dialect failures, you should correct the respective test file.</p><div class="top"><span class="topbutton"><a href="#top">Back to Top</a></span></div><h2><a id="sect6" name="sect6">6. Log file contents</a></h2><p>The tests in the log file are always text-copies of the tests from the test file, which means that they are not modified in any way. It is possible to run them in Rebol console as well as to find them using text search in the test file if desired.</p><p>Note that if the tests weren't text-copies, but just molded (using either <strong>mold</strong> or <strong>mold/all</strong> calls) versions of the tests, the text search would not be guaranteed to work. Furthermore, in some cases such modified tests would work differently.</p><div class="top"><span class="topbutton"><a href="#top">Back to Top</a></span></div><h2><a id="sect7" name="sect7">7. Filtering test logs</a></h2><p>Sometimes we are not interested in all test results preferring to see only a list of failed tests. The <strong>log-filter.r</strong> script can be used for that as follows:</p><pre class="example">e:\Ladislav\rebol\rebol-view.exe log-filter.r r_2_7_8_3_1_1DEF65_E85A1B.log</pre><p>The result is the file:</p><pre class="example">f_2_7_8_3_1_1DEF65_E85A1B.log</pre><p>, i.e., the file having a prefix #"f", otherwise having the same name as the original log file and containing just the list of failed tests.</p><div class="top"><span class="topbutton"><a href="#top">Back to Top</a></span></div><h2><a id="sect8" name="sect8">8. Comparing test logs</a></h2><p>We have seen that we obtained different test summaries for different interpreter versions. There is a <strong>log-diff.r</strong> script allowing us to obtain the list and summary of the differences between two log files.</p><p>The <strong>log-diff.r</strong> script can be run as follows:</p><pre class="example">e:\Ladislav\rebol\rebol-view.exe log-diff.r r_2_7_8_3_1_1 DEF65_E85A1B.log r_2_101_0_4_4_F9A855_E85A1B.log</pre><p>The first log file given is the "old log file" and the second file is "new log file".</p><p>The result is the <strong>diff.r</strong> file containing the list of the tests with different results and the summary as follows:</p><pre class="example">new-successes: 907
new-failures: 25
new-crashes: 4
progressions: 119
regressions: 94
removed: 302
unchanged: 3147
total: 4598</pre><p>Where, again, we see that the total number of tests was 4598. The count of "new- successes" expresses how many successful tests were newly performed (performed in the new log, but not performed in the old log), the count of "new-failures" expresses how many failing tests were newly performed, "new-crashes" expresses how many crashing tests were newly performed, the count of "progressions" expresses how many tests have improved results and the number of "regressions" expresses how many tests have worse results than before, "removed" expresses how many tests are not performed in the new log, "unchanged" expresses how many tests have the same result both in the old and in the new log.</p><p>Log difference is useful if:</p><ul><li>We want to know the effect of interpreter code update. In this case it is most convenient (but not required) to perform the same test suite using both the old as well as the new interpreter version and compare the logs.</li><li>We want to know the effect of test suite changes. In this case it is most convenient (but not required) to perform both the old and new test suite version using the same interpreter and compare the logs.</li></ul><div class="top"><span class="topbutton"><a href="#top">Back to Top</a></span></div><h2><a id="sect9" name="sect9">9. Features of the test dialect</a></h2><ul><li>In accordance with Carl's design intention, the test dialect is "Rebol compatible" and as simple as possible.</li><li>However, the test dialect is not handled by the test framework as Rebol code, because the tests contained in the test suite can be (and actually are) used to test different Rebol interpreters (both R2 and R3 in our case), every one of them having a different "idea" what "Rebol" is.</li><li>The fact that the test environment handles the test file as formatted text (i.e., not as Rebol code) complicates test file parsing a bit (not too much, since the format was designed by Carl Sassenrath to be simple), but it brings significant advantages:<ul><li>One test file can be used to test different (more or less source-code compatible) interpreters.</li></ul><ul><li>One of the properties that can be and actually is tested is the ability of the interpreter to load the test as Rebol code.</li></ul><ul><li>Since the test file is handled by the test framework as a text file having the format described below, the test framework is able to always record and handle the original "look" of the tests.</li></ul><ul><li>Therefore, the original tests cannot be "distorted" by any incorrect <strong>load/mold</strong> transformations performed by the interpreter.</li></ul><ul><li>Tests "stand for themselves" not needing any names. (Test writers can use whatever naming convention they prefer, but names are not required for the test framework to be able to handle the tests.)</li></ul><ul><li>Log files can be further postprocessed</li></ul><ul><li>There is a sophisticated <strong>log-diff</strong> function tailor-made to compare test logs</li></ul><ul><li>It is possible to filter log files if just the tests with specific results are examined</li></ul><ul><li>The fact that the filtered logs are obtained only from the postprocessing phase guarantees that no differences caused by incompatibilities in testing code can occur</li></ul></li><li>Issues are used to signal special handling of the tests. They are handled by the environment as flags excluding the marked test from processing. Only if all flags used are in the set of acceptable flags, the specific test is processed by the environment, otherwise it is skipped.</li><li>Every test has to be in properly matched square brackets.</li><li>A test is successful only if it can be correctly loaded and it yields <strong>true</strong> when evaluated. While this looks like a limitation, actually it allows any kind of checks (approximate equality of some result to some predetermined value, strict equality of some result to some predetermined value, sameness of certain examined values, or any other condition that can be written in Rebol).</li><li>Breaks, throws, errors, returns, return/redo's, etc. leading out of the test code are detected and marked as test failures.</li><li>The test environment counts successful tests, failed tests, crashing tests, skipped tests and test dialect failures, i.e., the cases when the test file is not properly formatted.</li><li>Files or URLs in the test file "outside" of tests are handled as directives for the test environment to process the tests in the respective file as well.</li><li>All "catchable" exceptions are caught, but there are code examples that cause interpreter or test environment crash. Such tests are detectable from the log file, but the processing of the test file stops since the interpreter or the environment crashed. Nevertheless, the test framework is built in such a way that it can recover from any kind of crash and finish the testing after the restart.</li></ul><div class="top"><span class="topbutton"><a href="#top">Back to Top</a></span></div><h2><a id="sect10" name="sect10">10 Test dialect</a></h2><h3><a id="sect10.1" name="sect10.1">10.1 Test cases</a></h3><p>Test cases have to be enclosed in properly matched square brackets</p><h3><a id="sect10.2" name="sect10.2">10.2 Comments</a></h3><p>Comments following the semicolon character until the end of the line are allowed.</p><h3><a id="sect10.3" name="sect10.3">10.3 Flags</a></h3><p>Issues are used to indicate special character of tests. For example,</p><pre class="example">#r2only</pre><p>indicates that the test is meant to be used only in R2. Flags restrict the usage of tests. If the <strong>do-recover</strong> function is called without a specific flag being mentioned in the <strong>flags</strong> argument, all tests marked using that flag are ignored. For example, if the above <strong>#r2only</strong> flag is not mentioned in the <strong>flags</strong> argument, no <strong>#r2only</strong> test is run. Any test may be marked by as many flags as desired.</p><p>The flags used when testing Rebol/Core are:</p><pre class="example">; the flag influences only the test immediately following it,
; if not explicitly stated otherwise</pre><pre class="example">#32bit
; the test is meant to be used only when integers are 32bit</pre><pre class="example">#64bit
; the test is meant to be used only when integers are 64bit</pre><pre class="example">#r2only
; the test is not meant to be used with the R3 interpreter</pre><pre class="example">#r3only
; the test is not meant to be used with the R2 interpreter</pre><pre class="example">#r3
; the test can work with R2 if using R2/Forward, or with R3</pre><h3><a id="sect10.4" name="sect10.4">10.4 Files/URLs</a></h3><p>Files or URLs specify what to include, i.e., they allow a file to contain references to other test files.</p><h3><a id="sect10.5" name="sect10.5">10.5 Example</a></h3><p>Here are some tests cases for the <strong>closure!</strong> datatype, notice that only some of them are marked as <strong>#r3only</strong>, suggesting they are meant just for the R3 interpreter:</p><pre class="example">; datatypes/closure.r
[closure? closure [] ["OK"]]
[not closure? 1]
#r3only
[closure! = type? closure [] ["OK"]]
; minimum
[closure? closure [] []]
; literal form
#r3only
[closure? first [#[closure! [[] []]]]]</pre><div class="top"><span class="topbutton"><a href="#top">Back to Top</a></span></div><h2><a id="sect11" name="sect11">11 How to contribute?</a></h2><h3><a id="sect11.1" name="sect11.1">11.1 The file containing tests</a></h3><p>The tests are in the <strong>core-tests.r</strong> file.</p><h3><a id="sect11.2" name="sect11.2">11.2 File format</a></h3><p>The test file is a text file in UNIX format (LF character used for line endings) and written using UTF-8 encoding.</p><h3><a id="sect11.3" name="sect11.3">11.3 Organization of tests</a></h3><p>As you may have already noticed there are some "sections" in the <strong>core-tests.r</strong> file. It is advisable to follow the structure or ask when in doubt (the present author also asked a couple of times) where to put the new test or tests.</p><h3><a id="sect11.4" name="sect11.4">11.4 Checking new tests</a></h3><p>To find out how to write new tests, you can consult the "Test dialect" section and have a look at actual tests in the <strong>core-tests.r</strong> file.</p><p>When you write new tests, it is best to run the tests again to find out whether some dialect failures did not occur. The presence of dialect failures signals that the tests need corrections (balancing brackets or something else).</p><p>After resolving dialect failures, it is best to run also <strong>log-diff.r</strong> to find out whether the new test log differs from the old one as intended.</p><p>Test as well as documentation contributions are welcome.</p><div class="top"><span class="topbutton"><a href="#top">Back to Top</a></span></div><h2><a id="sect12" name="sect12">12 How to run tests from Windows Explorer</a></h2><p>To run tests from Windows Explorer you need to create one or more associtations for Windows Explorer context menu.</p><h3><a id="sect12.1" name="sect12.1">12.1 How to add a new association for Windows Explorer in Windows Vista, Windows 7, Windows 8, Windows 10 or Windows 11</a></h3><p>Assume that you decided to use the <strong>.tst</strong> suffix for your test files. Then you can define commands like <strong>open</strong> and <strong>test</strong> in the Windows Explorer right-click context menu. I define the <strong>open</strong> command for editing the <strong>.tst</strong> files using the Notepad++ editor and the <strong>test</strong> command for running the tests. Both commands are defined using a <strong>tst_auto_file.reg</strong> file.</p><p>The contents of the <strong>tst_auto_file.reg</strong> file I am using (Do not forget to edit the file to reflect your setup and preferences.) are</p><pre class="example">Windows Registry Editor Version 5.00</pre><pre class="example">[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.tst]
@="tst_auto_file"</pre><pre class="example">[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\tst_auto_file]</pre><pre class="example">[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\tst_auto_file\shell]</pre><pre class="example">[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\tst_auto_file\shell\open]</pre><pre class="example">[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\tst_auto_file\shell\open\command]
@="\"C:\\Program Files\\Notepad++\\notepad++.exe\" \"%1\""</pre><pre class="example">[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\tst_auto_file\shell\test]</pre><pre class="example">[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\tst_auto_file\shell\test\command]
@="\"C:\\Develop\\Rebol\\rebview.exe\" -s C:\\Develop\\rebol-test\\run-tests.r \"%1\""</pre><h4><a id="sect12.1.1" name="sect12.1.1">12.1.1 Possible interferences</a></h4><div class="note"><div class="message"><p>After using the Windows 7, Windows 8 or Windows 10 built-in "Choose default program..." action (found under the file-right-click context menu under "Open with") it re-associates the extension with whatever new program you choose. What happens at this point is that <strong>HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.tst\UserChoice</strong>, and possibly <strong>HKEY_CURRENT_USER\Software\Microsoft\Windows\Roaming\OpenWith\FileExts\.tst\UserChoice</strong> are created/changed by the system, and so the newly selected program takes over. To regain control over the extension you can delete the above UserChoice key/keys.</p></div></div><div class="top"><span class="topbutton"><a href="#top">Back to Top</a></span></div><h2><a id="sect13" name="sect13">13 This documentation</a></h2><p>The source to this documentation is in the tests.mdp file. Any clarifications and improvements to it are welcome.</p><p>End of the article.</p><div class="top"><span class="topbutton"><a href="#top">Back to Top</a></span></div><hr /><p class="end">Document formatter copyright <a href="http://www.robertmuench.de">Robert M. Münch</a>. All Rights Reserved.<br />XHTML 1.0 Transitional formatted with Make-Doc-Pro Version:1.3.0 on 19-Apr-2024 at 10:44</p></body></html>