From: Thomas Walker Lynch Date: Tue, 5 Nov 2024 01:26:14 +0000 (+0000) Subject: release v1.0 X-Git-Url: https://git.reasoningtechnology.com/style/static/gitweb.css?a=commitdiff_plain;h=c246cb63e072c831556f5cc8112c4f975def3559;p=Mosaic release v1.0 --- diff --git a/developer/document/build_transcript.txt b/developer/document/build_transcript.txt new file mode 100644 index 0000000..29aa92c --- /dev/null +++ b/developer/document/build_transcript.txt @@ -0,0 +1,58 @@ +> cd Mosaic +> source env_developer +> emacs & + +... + +2024-11-04T11:19:53Z[Mosaic_developer] +Thomas-developer@Blossac§/var/user_data/Thomas-developer/Mosaic/developer§ +> clean_build_directories ++ cd /var/user_data/Thomas-developer/Mosaic/developer ++ rm -r scratchpad/com ++ rm jvm/Mosaic.jar ++ rm shell/Mosaic ++ set +x +clean_build_directories done. + +2024-11-04T11:20:14Z[Mosaic_developer] +Thomas-developer@Blossac§/var/user_data/Thomas-developer/Mosaic/developer§ +> wipe_release ++ cd /var/user_data/Thomas-developer/Mosaic ++ rm -rf release/Mosaic release/Mosaic.jar ++ set +x +wipe_release done. + +2024-11-04T11:20:18Z[Mosaic_developer] +Thomas-developer@Blossac§/var/user_data/Thomas-developer/Mosaic/developer§ +> make +Compiling files... ++ javac -g -d scratchpad javac/IO.java javac/Mosaic.java javac/TestBench.java javac/Util.java ++ set +x +Creating JAR file... ++ jar_file=jvm/Mosaic.jar ++ mkdir -p jvm ++ jar cf jvm/Mosaic.jar -C scratchpad . ++ set +x +JAR file created successfully: jvm/Mosaic.jar +Creating shell wrappers... +developer/tool/make done. + +2024-11-04T11:20:40Z[Mosaic_developer] +Thomas-developer@Blossac§/var/user_data/Thomas-developer/Mosaic/developer§ +> release +Starting release process... +Installed Mosaic.jar to /var/user_data/Thomas-developer/Mosaic/release with permissions ug+r +Installed Mosaic to /var/user_data/Thomas-developer/Mosaic/release with permissions ug+r+x +developer/tool/release done. + +2024-11-04T11:20:44Z[Mosaic_developer] +Thomas-developer@Blossac§/var/user_data/Thomas-developer/Mosaic/developer§ +> clean_make_output ++ cd /var/user_data/Thomas-developer/Mosaic/developer ++ rm -r scratchpad/com/ReasoningTechnology/Mosaic ++ rm jvm/Mosaic.jar ++ rm 'shell/{Mosaic}' +rm: cannot remove 'shell/{Mosaic}': No such file or directory ++ set +x +clean_make_output done. + diff --git a/document/An_Introduction_to_Structured_Testing.html b/document/An_Introduction_to_Structured_Testing.html index 0b29ab3..384beb2 100644 --- a/document/An_Introduction_to_Structured_Testing.html +++ b/document/An_Introduction_to_Structured_Testing.html @@ -621,7 +621,7 @@ the last row of the table, to have reasonable test times, there would be coverage 10-18 percentage coverage. At that level of coverage there is really no reason to test. Hence, this table is not limited to speaking about exhaustive - testing, rather is speaks to black box testing in general.

+ testing, rather it speaks to black box testing in general.

Informed Spot Checking

diff --git a/document/Tests_Writing_Output_Stream_Policy.html b/document/Tests_Writing_Output_Stream_Policy.html deleted file mode 100644 index 29bd872..0000000 --- a/document/Tests_Writing_Output_Stream_Policy.html +++ /dev/null @@ -1,112 +0,0 @@ - - - - - - - Output Stream Policy - Mosaic Project - - - -
-

Output Stream Policy for Tests

- -

Overview of the IO Object

- -

Each test function is given an IO object, which provides - methods for inspecting stdout and stderr output - streams, programmatically adding data to the stdin input stream, - and clearing output streams as needed. Although the IO object is - optional, it is available for cases where I/O validation or cleanup is - essential to the test.

- -

Purpose

- -

Each test function is responsible for managing any output generated - on stdout or stderr by the function under test - (fut). TestBench will automatically clear the streams before - each test begins and will check them after the test completes, treating any - remaining output as unintended and marking the test as a failure. This policy - ensures that tests intentionally handle output by either validating, - clearing, or ignoring it, thereby maintaining a clean and predictable testing - environment.

- -

Policy Guidelines

- - -

Example Scenarios

- - -

Summary

-

Each test should manage its output streams with an intentional policy:

- -

This approach ensures that tests remain clean and focused on their primary objectives without unintended side effects from unhandled output.

-
- - diff --git a/document/adder64.odg b/document/adder64.odg deleted file mode 100644 index 942c77f..0000000 Binary files a/document/adder64.odg and /dev/null differ diff --git a/document/bash_name_of_script.txt b/document/bash_name_of_script.txt new file mode 100644 index 0000000..3637574 --- /dev/null +++ b/document/bash_name_of_script.txt @@ -0,0 +1,40 @@ + +Bash is inconsistent about returning the name of the running script in +all scenarios (sourced, executed directly, from with in a function called +by another function). + +1. + +BASH_SOURCE[0] was used because $0 did not work with sourced scripts (a +fact that is leveraged for detecting when in a sourced script). + +2. + +However, this did not work in all scenarios: + + read -r -d '' script_afp_string <<'EOF' + realpath "${BASH_SOURCE[0]}" 2>/dev/null + EOF + + script_afp(){ + eval "$script_afp_string" + } + + export script_afp_string + export -f script_afp + +When `script_afp` was exported, used in another file, and used within a function +in that other file, it reported `environment` for the script name at +BASH_SOURCE[0]. In various call scenarios the actual script name appears at +BASH_SOURCE[1] or even at BASH_SOURCE[2]. + +3. + +As a stable alternative to having a script_afp function, place this line +at the top of scripts that use the `script_XX` functions, or at the top +of all scripts: + + script_afp=realpath "${BASH_SOURCE[0]}" + +Then use $script_afp as a string within other functions. It will have stable +value no matter the call structure. diff --git a/document/directory_naming.html b/document/directory_naming.html index be43a3d..d409362 100644 --- a/document/directory_naming.html +++ b/document/directory_naming.html @@ -102,9 +102,7 @@
  • tester/ Workspace for the tester. Has the test bench, tests, and test scripts.
  • tool/ Project administration specific tools.
  • diff --git a/document/return_script_name.txt b/document/return_script_name.txt deleted file mode 100644 index 43738db..0000000 --- a/document/return_script_name.txt +++ /dev/null @@ -1,39 +0,0 @@ - -I had a lot of problems in bash scripting language, while trying to export a -function that could report the name of the script it was called in. - -1. - -BASH_SOURCE[0] was used because $0 did not work with sourced scripts (a -fact that is leveraged for detecting when in a sourced script). - -2. - -Hence, this did not work in general: - - read -r -d '' script_afp_string <<'EOF' - realpath "${BASH_SOURCE[0]}" 2>/dev/null - EOF - - script_afp(){ - eval "$script_afp_string" - } - - export script_afp_string - export -f script_afp - -When `script_afp` was exported, used in another file, and used within a function -in that other file, it reported `environment` for the script name at -BASH_SOURCE[0]. In various call scenarios the actual script name appears at -BASH_SOURCE[1] or even at BASH_SOURCE[2]. - -3. - -As a stable alternative to having a script_afp function, place this line -at the top of scripts that use the `script_XX` functions, or at the top -of all scripts: - - script_afp=realpath "${BASH_SOURCE[0]}" - -Then use $script_afp as a string within other functions. It will have stable -value no matter the call structure. diff --git a/document/work_flow.txt b/document/work_flow.txt index 5f699a2..6c3ea4c 100644 --- a/document/work_flow.txt +++ b/document/work_flow.txt @@ -29,7 +29,7 @@ 4.1. The release candidate is located in the `$REPO_HOME/release` directory and has passed testing. -4.2. Check that the program `$REPO_HOME/tool_shared/bespoke/release` outputs the +4.2. Check that the program `$REPO_HOME/tool_shared/bespoke/version` outputs the correct information. If necessary, modify it. 4.3. A new branch is created in the project for the release, named `release_v.0`, where `v.0` is the version number from the `version` diff --git a/release/Mosaic.jar b/release/Mosaic.jar index dd5ec49..f1f8c7a 100644 Binary files a/release/Mosaic.jar and b/release/Mosaic.jar differ diff --git a/tester/document/Tests_Writing_Output_Stream_Policy.html b/tester/document/Tests_Writing_Output_Stream_Policy.html new file mode 100644 index 0000000..29bd872 --- /dev/null +++ b/tester/document/Tests_Writing_Output_Stream_Policy.html @@ -0,0 +1,112 @@ + + + + + + + Output Stream Policy - Mosaic Project + + + +
    +

    Output Stream Policy for Tests

    + +

    Overview of the IO Object

    + +

    Each test function is given an IO object, which provides + methods for inspecting stdout and stderr output + streams, programmatically adding data to the stdin input stream, + and clearing output streams as needed. Although the IO object is + optional, it is available for cases where I/O validation or cleanup is + essential to the test.

    + +

    Purpose

    + +

    Each test function is responsible for managing any output generated + on stdout or stderr by the function under test + (fut). TestBench will automatically clear the streams before + each test begins and will check them after the test completes, treating any + remaining output as unintended and marking the test as a failure. This policy + ensures that tests intentionally handle output by either validating, + clearing, or ignoring it, thereby maintaining a clean and predictable testing + environment.

    + +

    Policy Guidelines

    +
      +
    • 1. Define an Output Handling Policy:
    • +
        +
      • Every test should have a defined policy for how it handles output generated by the fut. There are three primary approaches:
      • +
          +
        • Validation: Check the fut output and confirm its correctness.
        • +
        • Intentional Ignoring: If output validation isn’t relevant to the test, the output should still be acknowledged and cleared to avoid unintended failures.
        • +
        • Mixed Policy: A test can validate specific output while ignoring others, as long as any remaining output is cleared before the test returns.
        • +
        +
      + +
    • 2. When to Validate Output:
    • +
        +
      • If the test expects specific output from the fut, it should retrieve and check the content on stdout and stderr using methods like io.get_out_content() or io.get_err_content(). The test passes if the actual output matches the expected content.
      • +
      • After validating, the test should clear the output buffers (io.clear_buffers()) if further output handling is not needed to avoid residual content.
      • +
      + +
    • 3. When to Ignore Output:
    • +
        +
      • If the test does not require output verification, it should acknowledge the output by clearing the streams before returning.
      • +
      • This approach signals to TestBench that any output generated was intentionally disregarded and avoids marking the test as failed.
      • +
      + +
    • 4. Failure Due to Residual Output:
    • +
        +
      • No Defined Policy: If a test leaves output on the streams without a clear handling policy (validation or intentional clearing), TestBench will flag this as a failure.
      • +
      • Ensuring Clean Tests: To avoid unexpected failures, verify that each test has no residual output before returning by either validating or clearing output streams.
      • +
      +
    + +

    Example Scenarios

    +
      +
    • 1. Output Validation:
    • +
      public static Boolean test_with_output_verification(IO io) {
      +  System.out.println("Expected output");
      +  String output = io.get_out_content();
      +  boolean isCorrect = output.equals("Expected output");
      +  io.clear_buffers(); // Clear remaining content if not needed
      +  return isCorrect;
      +}
      + +
    • 2. Ignoring Output:
    • +
      public static Boolean test_without_output_verification(IO io) {
      +  System.out.println("Output not needed for this test");
      +  io.clear_buffers(); // Clear output since it’s intentionally ignored
      +  return true;
      +}
      +
    + +

    Summary

    +

    Each test should manage its output streams with an intentional policy:

    +
      +
    • Validate output if it is relevant to the test.
    • +
    • Acknowledge and clear output if it is not relevant.
    • +
    • Avoid residual output to prevent TestBench from marking the test as failed.
    • +
    +

    This approach ensures that tests remain clean and focused on their primary objectives without unintended side effects from unhandled output.

    +
    + + diff --git a/tester/document/build_run_transcript.txt b/tester/document/build_run_transcript.txt new file mode 100644 index 0000000..d5c1d45 --- /dev/null +++ b/tester/document/build_run_transcript.txt @@ -0,0 +1,64 @@ +This shows all tests passing. + +It can be a bit confusing to read, but the failure results from the tests named +'test_failure_X' are actually passing when they report that they failed. This is +because we are testing a test bench, and we are testing the feature of the test +bench where it fails bad code. + +> cd Mosaic +> source env_tester +> emacs & + +... + +2024-11-04T11:23:08Z[Mosaic_tester] +Thomas-developer@Blossac§/var/user_data/Thomas-developer/Mosaic§ +> clean_build_directories ++ cd /var/user_data/Thomas-developer/Mosaic/tester ++ rm -r scratchpad/Test0.class scratchpad/Test_IO.class 'scratchpad/Test_MockClass$TestSuite.class' scratchpad/Test_MockClass.class scratchpad/Test_TestBench.class scratchpad/Test_Util.class ++ rm jvm/Test_Mosaic.jar ++ rm shell/Test0 shell/Test_IO shell/Test_MockClass shell/Test_TestBench shell/Test_Util ++ set +x +clean_build_directories done. + +2024-11-04T11:23:23Z[Mosaic_tester] +Thomas-developer@Blossac§/var/user_data/Thomas-developer/Mosaic§ +> make +Compiling files... ++ cd /var/user_data/Thomas-developer/Mosaic/tester ++ javac -g -d scratchpad javac/Test0.java javac/Test_IO.java javac/Test_MockClass.java javac/Test_TestBench.java javac/Test_Util.java ++ jar cf jvm/Test_Mosaic.jar -C scratchpad . ++ set +x +Creating shell wrappers... +tester/tool/make done. + +2024-11-04T11:23:27Z[Mosaic_tester] +Thomas-developer@Blossac§/var/user_data/Thomas-developer/Mosaic§ +> run_tests +Running Test0...Test0 passed +Running Test_Util...Test_Util passed +Running Test_IO...Test_IO passed +Running Test_TestBench...Expected output: Structural problem message for dummy_invalid_return_method. +Structural problem: dummy_invalid_return_method does not return Boolean. +Test_TestBench Total tests run: 3 +Test_TestBench Total tests passed: 3 +Test_TestBench Total tests failed: 0 +Running Test_MockClass...Test failed: 'test_failure_0' reported failure. +Structural problem: test_failure_1 does not return Boolean. +Error: test_failure_1 has an invalid structure. +Test failed: 'test_failure_2' threw an exception: java.lang.reflect.InvocationTargetException +Test failed: 'test_failure_3' produced extraneous stdout. +Test failed: 'test_failure_4' produced extraneous stderr. +Total tests run: 9 +Total tests passed: 4 +Total tests failed: 5 + +2024-11-04T11:23:33Z[Mosaic_tester] +Thomas-developer@Blossac§/var/user_data/Thomas-developer/Mosaic§ +> clean_build_directories ++ cd /var/user_data/Thomas-developer/Mosaic/tester ++ rm -r scratchpad/Test0.class scratchpad/Test_IO.class 'scratchpad/Test_MockClass$TestSuite.class' scratchpad/Test_MockClass.class scratchpad/Test_TestBench.class scratchpad/Test_Util.class ++ rm jvm/Test_Mosaic.jar ++ rm shell/Test0 shell/Test_IO shell/test_log.txt shell/Test_MockClass shell/Test_TestBench shell/Test_Util ++ set +x +clean_build_directories done. diff --git a/tester/jvm/Test_Mosaic.jar b/tester/jvm/Test_Mosaic.jar index 73b5565..9d9305e 100644 Binary files a/tester/jvm/Test_Mosaic.jar and b/tester/jvm/Test_Mosaic.jar differ diff --git a/tester/shell/test_log.txt b/tester/shell/test_log.txt new file mode 100644 index 0000000..0271459 --- /dev/null +++ b/tester/shell/test_log.txt @@ -0,0 +1,14 @@ + +2024-11-04T13:53:57.865246Z ----------------------------------------------------------- +Test: test_failure_3 +Stream: stdout +Output: +Intentional extraneous chars to stdout for testing + + +2024-11-04T13:53:57.874296Z ----------------------------------------------------------- +Test: test_failure_4 +Stream: stderr +Output: +Intentional extraneous chars to stderr for testing. + diff --git a/tool_shared/bespoke/version b/tool_shared/bespoke/version index 3a9dd05..7faa3a1 100755 --- a/tool_shared/bespoke/version +++ b/tool_shared/bespoke/version @@ -2,5 +2,5 @@ script_afp=$(realpath "${BASH_SOURCE[0]}") # 2024-10-24T14:56:09Z project skeleton and test bench files extracted from Ariadne -echo v0.1 +echo v1.0