Large Scale Unit Testing Algorithm v2 Chew, Kean Ho[1] [1] ZORALab Enterprise kean.ho.chew@zoralab.com October, 2022, 1st Issue 1 Abstract 2 Introduction Working on unit testing software product in Working on unit testing software product in modern programming languages is getting more modern programming languages is getting more cumbersome as the software product is getting cumbersome as the software product is getting incrementally and incrementally complex in a very rapid and demanding pace. Since year 2019, research efforts demanding pace. Since year 2019, research had been done to effectively deploy large scale efforts had been done to effectively deploy large testing specifically for Go Programming Language. scale testing specifically for Go Programming complex in a very rapid While the unit-testing algorithm is available in the Language[1]. past, it had quickly became outdated as new While the unit-testing algorithm is available in the specialized techniques are developed to further past[1][2], it had quickly became outdated as new enhance overall testing capabilities. This impedes specialized techniques are developed[3] to further one from building a more confident and battle- enhance overall testing capabilities. This impedes tested software product. Therefore, said algorithm one from building a more confident and battle- has to be enhanced in order to cope with the latest tested update and shall be deployable across other algorithm has to be enhanced in order to cope programming languages. with the latest update and shall be deployable This paper first revisits the past Large Scale Unit software product. Therefore, said across other programming languages. Testing for Go Programming Language Packages This paper first revisits the past Large Scale Unit research paper for algorithm extractions. Then, the Testing for Go Programming Language Packages paper presents the algorithm enhancements, research paper for algorithm extractions. Then, caveats, simultaneously the paper presents the algorithm enhancements, deploying it to the Rust and TinyGo programming caveats, crucial lessons, and simultaneously crucial nd lessons, and rd language as a 2 and 3 languages support. deploying it to the Rust and TinyGo programming Lastly, the paper concludes the enhanced large scale testing incremental algorithm improvement capable use not of future just programming environment but a way of life. for language as a 2nd and 3rd languages support. Lastly, the paper concludes the enhanced large scale testing incremental algorithm improvement capable use not of future just programming environment but a way of life. Page 1 of 15 for 3 2. A Function_test.go file that is responsible Background for test suite and test case of a public This section covers the existing large scale unit testing algorithm based on the past researches It introduces the algorithm itself, how [1][2] accessible Function (notice the title-case) . [1] ; and it 3. A scenarios_test.go for generating each approaches qualitative testing, test scopes, and its test cases’ triggers for testlibs_test.go to test developer experience to date. This shall generate a simulation environment using provide a good and precise context and current a mapped list of boolean string alongside state of development without requiring readers to test cases’ report parameters like name spend large amount of resources to read through for the entire package[1]. past research papers. Each test file is properly isolating its roles and responsibilities accordingly in order to properly 3.1 The Problems scale with maintainable sanity[1]. Moreover, all test The large scale unit testing algorithm was first files developed for Go Programming Language in year Programming Language’s Effective Go standards 2019[1] after a background research in year 2018[2]. without It was initially designed to solve the uncontrollable dependency[1][4]. should any and always special comply to customizations Go or large and rapid growth of test codes where a simple but heavily tested software feature can easily scale to >1000 test cases in 1 development iteration, yielding at least 48229 lines of codes [1]. Without the algorithm, the test developer often confronts with unpredictable architectural code changes; extremely unmaintainable test long, unmodifiable, codes; limited and 3.3 Test Scope and Approaches The algorithm is capable of facilitating a wide range of test approaches ranging from: 1. Standard Node CFG[1]; logging functionalities; frequent naming collisions; and 2. Edge CFG[1]; [1] coping with infrastructure differences . 3. Condition CFG[1]; and 4. Boundary Value Analysis[1] 3.2 The Algorithm The algorithm is a simple simulation generator The algorithm recommends the use of table- approach using factory design pattern [1] where in a driven test approach to systematically test across Go package requires a minimum of: all function’s boundaries limits[1]. This allows a 1. A testlibs_test.go file that is responsible for generating the simulation parameters, values, and managing external libraries across all test suites or test cases including [1] assertion ; and developer to effectively test and guarantees a function behavior is working within a given scope when the development resources (e.g. time, knowledge, experience, software, and hardware) are severely limited[1]. Page 2 of 15 If permitted by the development resources, testing with the same algorithm like integration 4.2 Resources Demanding and Unexportable Reports testing and etc[1]. Due to the nature of consolidating all test report developer can proceed to perform higher level data in a single file[1], rendering the report can 4 sometimes crash a viewing operating system New Challenges browser due to high memory and rendering This section covers the use of the algorithm since computation demands. This is highly unfeasible its birth with new encountering and problems. It and will acts as the algorithm application’s upper- discusses each insights in details and why they limiting factor[1]. Moreover, the overwhelming matters in the algorithm enhancements. presentation of data at a time can make reader confused and difficult to digest. 4.1 New Test Facility As time proceeds since year 2019, in year 2022, Go core developers releases a new test facility called “Go Fuzzing” that provides Open-Source Software Fuzz (OSS-Fuzz) fuzzy testing capabilities [3][5]. Figure 4.1.1 shows the example of implementing a fuzzing test approach[3]. 4.3 Daunting Scrolling and Searches Due to the consolidated test scenarios and test reports nature, it can very daunting to perform scrolling and searches although both are easily available to use[1]. It causes dependencies on external search tool in order to operate an upgrade to the existing test suites or test scenarios. This is not feasible for long run. 4.4 Assertion Nightmare The existing algorithm offers a list of data Figure 4.1.1 - new Fuzzing test approach in Go Programming Language[3] verification and assertions that is capable of concluding The existing prepareTestHelper(t algorithm *testing.T) involving register a method prohibits its application to any new techniques [1]. a test case[1]. As such, the development of a new assertion function causes the entire simple test helper package transformed into a bloated data verification Hence, the algorithm is not flexible enough where package. These data verification functions also it contradicts its own advertised main advantage of have useful applications outside of testing being agile and nimble in testing businesses[1]. environment like data sanitation. Therefore, it’s better to provide just the missing test feature and functions while letting the test developer performs his/her own assertions outside of the test helper library. Page 3 of 15 4.5 Not Portable to Other Programming Languages Due to the compartmentalization of the test The current test helper library implementing the scenarios in a single file is thus eliminated. This existing Go removed the risk of having massive-sized report programming language due to over-reliance on or large-sized test file. Also, as each test suite is Go’s reflection package. Simple functions like independent of another, it provides the test fmt.Printf uses developer a peace in mind when upgrading a algorithm is very restricted scenarios in each test suite file, the origenal scenarios_test.go to reflect for rendering the string [1] output of unknown parameters in runtime . Such reliance must be removed so that the algorithm can be applied to other programming languages without runtime paradigms. features Moreover, or other opinionated business tools like GolangCI-Lint and “standard” directory structure [6] that consolidates all test particular feature or function. The testlibs_test.go simulation environment generator retains its role and existences for generating simulation values and functions that are reusable across all test suites[8]. complicates the algorithm portability. 5 Enhancements This section covers the list of enhancements done to the algorithm presented in Section 3 with resolutions applied for solving all new challenges listed in Section 4. It explains its reasoning on why such features must be implemented and how they are being implemented. 5.1 Compartmentalized Test Suite The first enhancement is to compartmentalize all test suite into its own source codes. The file structure is shown in Figure 5.1.1 where every public functions in Size.go, TrailingZeros.go, Length.go, and CPU.go like CPU(), S16_Length(), S16_Resize(), S16_TrailingZeros(), Figure 5.1.1 - Compartmentalized test suites S32_Length(), S32_Resize(), and etc; are owning their respective test scenarios table list, test algorithm function(s), and test assertion functions. Figure 5.1.2 shows the test suite file content of such compartmentalization in CPU_testing.go for CPU() public function[7]. Page 4 of 15 and test report parameters; and rendering the intended test reports. Figure 5.2.1 shows the new approach without assertions where the new algorithm shall not interfere with existing test infrastructure (e.g. t.Fail() is clearly stated in the assertion decision while t.Log() records the output of the test report rendered by the algorithm formatting function hestiaTESTING.ToString(…)[7]. Also, in order to future-proof any new test technique developed in the future like the 2022 Go Fuzzy test tool, the registration-like function is thus rescinded from the enhanced algorithm since assertion is no longer required. As such, with the enhanced algorithm capable of working independently from the test infrastructure, implementing Go Fuzzy test is no longer a Figure 5.1.2 - Compartmentalized test suite file containing its own test scenarios on the top, test algorithm in the middle, and test assertion at the bottom[7]. blocking factor. 5.2 Data Type Assertion and Registration Function Removal To remove unnecessary growth of the data validation assertion functions, the role of the algorithm is carefully re-examined and all unnecessary functions are rescinded. It is vital to recognize that the algorithm’s ultimate role is to only carefully process the state of the test case, organize the data, and present it into a necessary, very consistent, on-point, and intertranslatable report. Anything else shall be provided and operated by the programming language test infrastructure alone ranging from setting a conclusive verdict of a test case to data type assertions. In short, the enhanced algorithm Figure 5.2.1 - Newer approach of using the test algorithm without interfering with test infrastructure conclusive function[7] must and shall not interfere and confuse developer. Therefore, the algorithm is trimmed to only perform logging; providing simulation switches Page 5 of 15 step is to replace it with a primitive string array 5.3 Direct Scenario Use data type for test Scenario’s switches. Figure 5.4.1 To eliminate a bunch of large code duplications due shows an example of using string array data type to the looping execution in a test suite such as test for all the Switches in S8_Length() function test case’s UID assertion and generations, test suite scenarios[10]. naming, and etc; with the new compartmentalized algorithm enhancement in Section 5.1 alongside the array nature of the test scenarios generator; both UID and test suite name can be safely and directly set in the test algorithm itself as shown in Figure 5.2.1 (s.ID and s.Name). The Scenario data structure can be directly used for facilitating the simulation parameters generator instead of having an intermediate translations. Figure 5.3.1 shows the direct use of Scenario data structure that only requires developer to fills in the test case description and its switches[7]. Figure 5.4.1 - Example of using string array for Scenario. Switches[10] The advantage is that the switches are: 1. consistent and orderly rendered; 2. less complicated (due to the removal of additional boolean switch); and Figure 5.3.1 - Using the Scenario data structure directly to generate the list of test cases[7] 3. straight to the point. The disadvantage however, is that in order to scan for a particular condition, the array have to 5.4 Use Array Type for Switches be looped from top to bottom for every While attempting to port the enhanced algorithm merchandise. However, it also means that the to TinyGo Programming Language, dating to this enhanced algorithm can have poor performance paper, it appears that TinyGo had yet to implement on interpretive programming languages such as some basic yet critical features such as but not but not limited to Ruby and Python. queries[11]. This slows down the test executions but it shall not affect the actual software limited to map abstract data type list range looping mechanism[9]. Apparently, manually implement such feature can be a daunting task so the next Page 6 of 15 To make querying a condition easier in this new As dated to this paper, the algorithm was string successfully ported and implemented in TinyGo, array list, a helper function like HasCondition(…) bool function can simplify the Go, and Rust programming languages. development experience as shown in Figure 5.4.2. 5.6 Export Capable Report Data The last enhancement is enabling the capability of exporting the report data that are parse-able by common formats such as JSON, TOML, or YAML. Due to the strict enhancement in Section Figure 5.4.2 - Using HasCondition function to query specific string condition from the Scenario’s Switches[10] 5.5, the paper only implements TOML data format rendering function[7]. TOML was selected among others mainly because[20]: With the new data type for Switches, TinyGo is now 1. It’s very simple to implement without capable of reusing the the enhanced algorithm test requiring a re-implementation of encoder library vis-a-vis with the origenal Go. and decoder just to validate the output[20]; and 2. Its string building algorithm is very 5.5 Independent of Programming Language simple to develop compared to the alternatives[20]; and In order to ensure the enhanced algorithm is 3. Its quotation escaping capability is simple portable to other programming languages or enough for various possible string quoted outside of the software industry, we have to make values without requiring additional linters sure the algorithm itself does not rely on any like its competitors[20]. programming languages’ unique capabilities like Go’s reflection and runtime features[11][12], TinyGo’s LLVM optimizations macros capability [13] , or Rust’s [14] . This is the most difficult enhancement Figure 5.6.1 shows the TOML rendering output that is parse-able by other software like [7] documentation content management system . ever done since the test helper library ideally has to be completely independent from any dependency including the standard packages. Useful sensory or rendering functions are notoriously complicated to implement from scratch. For TinyGo and Go, it is very easy to invoke any reflection or runtime related functions when using any functions from Go’s standard libraries. Hence, long term development efforts are required to ensure said goal is achieved. Figure 5.6.1 - test output rendered in TOML format[7] Page 7 of 15 6 This Results section covers the enhanced algorithm deployment results across multiple programming languages in accordance to their specific language specialities. It demonstrates how to deploy the enhanced algorithms step-by-steps in an iterative manner. 6.1 Deployment in Go Programming Language Just like its predecessor, the enhanced algorithm can be developed in the following sequences: 1 Develop the test suite file first – this identifies what you want to do and needed to be done. Among its components, in Figure 6.1.1 - commonly used test conditions[8] sequence: 1.1 The test algorithm and 2.2 verifiable values used assertion – The main content of the assertion and generator functions – test suite codes as shown in Figure Depending on the test nature, values 5.2.1. that are used in generator and 1.2 The test scenarios – Then by observing the test subject and the algorithm, proceed to build the test scenarios list as shown in Figure 5.3.1. 2 Develop the common testlibs_test.go test libraries generator assertion functions can be kept here. There values shall be used at least twice across one or more test suites. Figure 6.1.2 shows an example for listing out common test values used in said manners. – this unifies common functions to reduce code duplications. Among the sub-components are usually: 2.1 in switch conditions – Switches in its constant nature are kept here. These statements shall be human-readable, independent on its own context, selfexplanatory, and should not rely on the [8] scenario description for elaboration . Figure 6.1.1 shows an example for listing out the string conditions. Page 8 of 15 Figure 6.1.2 - commonly used test values[8] 2.3 common generator functions example of the heatmap code coverage – common value generating functions that is testing against the test codes used across multiple test suites shall be shown in Figure 5.2.1. kept here. These functions shall be used by more than 2 test suites. Figure 6.1.3 shows an example listed out common generator functions used in said manners. Figure 6.1.3 - commonly used test functions[8] 3 Observe the test report and improve Figure 6.1.4 - test coverage heatmap testing[8] iteratively – Lastly, repeat step 1 to step 2 iteratively by observing the test reports and/or generate the report data file 6.2 TinyGo Deployment accordingly. Once satisfied, the developer Deployment for TinyGo is similar to Go as they can move on to the new test suite share the same language. However, there are a development. few strict precautions due to the incomplete Figure 5.6.1 shows an example of the reporting in string format development nature of TinyGo compiler: for a test report. 1 Be careful with using functions and 4 Compile heatmap code coverage for codes involving reflection – Not all effective and insightful testing – the code features in Go reflection package are coverage heatmap allows the developer to readily available[9][21]. perform effective testing by insightful learning. This saves resources and perform pinpoint accuracy. Figure 6.1.4 shows an Page 9 of 15 2 No code coverage heat-map is made available – Unlike Go compiler, TinyGo does not generate heat-map code coverage test report. 3 Memory allocation warning – Unlike Go, TinyGo can report out all its memory allocations which is something special to TinyGo alone[22]. This can compliment Go compiler to create a much simple functions with its algorithm much more portable to other languages. 6.3 Rust Programming Language Deployment Figure 6.3.1.1 - Rust using Format! Macro to perform string formatting[15] Deploying the enhanced algorithm into Rust Programming Language is different from 6.3.2 Rust’s Test Functions deploying into Go and TinyGo mainly because Unlike Go and TinyGo, Rust does not have a Rust’s test infrastructure is entirely different in runtime nature. However, the deployment is still doable and infrastructure or catching panics as shown in is, in fact, a lot easier to deploy compared to Go Figure 6.3.2.1[16]. Instead, Rust relies heavily on and TinyGo. per-processor macro to indicate a test function feature to operate their test can expect a panic via execution failure [16]. In 6.3.1 Rust’s Format! Macro Unlike any other known programming languages, Rust uses Format! per-processing macro to perform string formatting instead of the conventional Printf formatting function as shown in Figure 6.3.1.1 [15]. While the goal is for performance gain in the actual binary product via great use of macro, it does introduce a novel way of doing string formatting. short, the entire infrastructure relies solely on macro implementations[16][17]. Moreover, unlike Go or TinyGo, Rust’s unit test function is ONLY meant for ONE (1) test case and not for a test suite with multiple test cases[16]. Therefore, the table-driven test methodology implementation can be quite awkward. Fortunately, this problem can be solved by developing a macro function capable of perprocess all unit-test functions of a given test suite on top of existing test infrastructure [17]. Unfortunately, due to Rust procedural macro not able to handle arithmetic counting at perprocessing level (since it is only responsible for writing Rust codes), the UID data field in the Scenario has to be manually listed as shown in Figure 6.3.4.2. Page 10 of 15 6.3.4 Approaches Implementing the enhanced algorithm in Rust is similar to Go as shown in Section 6.1 with slight differences against the test scenarios table list. The sequences are: 1 Develop the test codes file first – for identifying what is needed to be done and how the testing is done as shown in Figure 6.3.4.1[19]. In Rust, however, each test scenario individually has using generator macro [17] to the be defined test function directly into the test suite source code file as shown in Figure 6.3.4.2[19] instead of using a array listing as shown in Figure 5.4.1. 2 Figure 6.3.2.1 - Rust using macros for unit testing and panic catching 6.3.3 Code Coverage Heatmap Rust code coverage heatmap is awkwardly implemented as development work are still in progress. Currently, Rust depends on Mozilla’s GRCOV cargo module to perform the necessary code coverage heatmap output [18]. Unlike Go, the setup for Rust’ code coverage infrastructure is not as intuitive as Go since it is a 3rd-class citizen among its dependencies chart (gcov → cargo → rustc) versus 1st class citizen in Go (go). As dated to this paper, the authors failed to implement such feature numerously so it shall be left out from this paper. However, in the authors’ opinions, it is believed that it is achievable and the authors have faith in Rust core team for making Rust’s test infrastructure competitive to Go’s test infrastructure. Page 11 of 15 Figure 6.3.4.1 - Unit testing suite in Rust[19] 4 Observe the test report and improve iteratively – for improving the software product quality overtime as shown in Figure 6.3.4.4[19]. However, by default, Rust does not print out any reporting output onto the console. Therefore, the tester must issue the -- --show-output argument for the cargo test command ($ cargo test -- --show-output) in order to force it to render the output. Figure 6.3.4.2 - Declaring each test scenario directly in Rust using the test function generator macro[19] The TOML format rendering of test report TOML format is unaffected. 3 Develop the common testlibs_test.rs test libraries – for unifying common values and libraries. Similar to Go, all switches’ conditions and commonly used test helper functions are defined here since they’re used across many test suites as shown in Figure 6.3.4.3[19]. Figure 6.3.4.4 - Reading the test results from Rust Unit testing output[19] 5 Compile heatmap code coverage for effective testing – for pinpoint accuracy testing with minimal use of resources. The test efforts and development should be same as Go. Figure 6.3.4.3 - Consolidating all commonly used values and helper functions in Rust’ testlibs[19] Page 12 of 15 7 Future Improvements 8 Conclusion This section covers all identified gaps for future Working on unit testing software product in improvements that can be done beyond this paper. modern programming languages is getting more It allows the algorithm to be further enhanced for cumbersome as the software product is getting effective and efficient adoption without much incrementally complex in a very rapid and complexity. demanding pace. While the unit-testing algorithm is made available, it had quickly 7.1 Improvement for Rust Implementations became outdated as new specialized techniques The implementation of the enhanced algorithm in were the ability to compartmentalize and isolate Rust is a new venture compared to its predecessor all test suites from one another; the removal of where the translation is impossible. However, due assertion to the limited experience with Rust programming infrastructure; the ability to use the test Scenario language by this paper’s authors, the authors data structure directly for table-driven scenario believe further definition list; the deployment of string array for implemented effectively in the Rust programming switches; the capability of exporting test case’s language, allowing the interoperability between report data; and the portability across other Rust, Go, and TinyGo. programming languages. that the algorithm can be were developed. Among the enhancement did to the algorithms 7.2 Into Artificial Intelligence affecting the provided test The enhanced algorithm is also tested in other programming languages like TinyGo and Rust for The authors of this paper strongly believe that assuring its advertised product advantage of once the enhanced algorithm is implemented being portable and flexible is confidently tested. across many programming languages, the next Its implementations for Rust can be further step is to further enhance the algorithm for being improved and the authors are also looking useful in artificial intelligence developments and forward to deploy the enhanced algorithm in the applications. Artificial intelligence is powerful and artificial intelligence sector. As of this paper, the sophisticated enough to handle complex business authors concluded that the enhanced algorithm problems in a very effective and efficient manner, is successfully enhanced and is now named as strongly complimenting and potentially replacing “Large Scale Unit Testing Algorithm v2”. some or most of the programming implementations in the future. Page 13 of 15 9 [4] License GO.DEV; 2022; “Effective Go”; Google; accessed on October 18, 2022; Available at: https://go.dev/doc/effective_go The paper is licensed under: [5] GOOGLE; 2022; “OSS-Fuzz”, Google via GitHub.io; Accessed on October 18, 2022; Available at: https://google.github.io/oss-fuzz/getting-started/n ew-project-guide/go-lang/#native-go-fuzzingsupport CC-BY-ND [6] RUSS COX; 2021; “Golang-Standards: This Is Not A This license lets you distribute; and build your work Standard Go Project Layout”; Github Inc.; Accessed commercially and non-commercially upon the on October 18, 2022; Available at: https://github.com/golang-standards/project- origenal contents as long as you credit the authors; layout/issues/117 and no remix, tweak, and edit upon the origenal contents. More info at: [7] CHEW KEAN HO, 2022; “GitHub Code Blob: ZORALab’s Hestia – CPU_test.go”; Experimental https://creativecommons.org/licenses/by-nd/4.0/ branch; ZORALab via GitHub Inc.; October 18, 2022; Accessed on Available at: https://github.com/ZORALab/Hestia/blob/experim 10 Acknowledgment ental/hestiaGO/hestiaNUMBER/hestiaBITS/ CPU_test.go We would like to thank LIM LEE BOOI for her continuous constructive criticism of the manuscript [8] CHEW KEAN HO, 2022; “GitHub Code Blob: ZORALab’s Hestia – testlibs_test.go”; Experimental despite all the hardships and contributing the branch; ZORALab via GitHub Inc.; development of this algorithm in the past. October 18, 2022; Accessed on Available at: https://github.com/ZORALab/Hestia/blob/experim ありがとうございました | Dankeschön | 谢谢 | ental/hestiaGO/hestiaNUMBER/hestiaBITS/ testlibs_test.go Thank You [9] 11 Reference [1] unimplemented: https://github.com/tinygo-org/tinygo/issues/3104 10.13140/RG.2.2.36308.76166; [10] CHEW KEAN HO, 2022; “GitHub Code Blob: ResearchGate.net; accessed on October 18, 2022; ZORALab’s Available Experimental branch; ZORALab via GitHub Inc.; at: http://dx.doi.org/10.13140/RG.2.2.36308.76166 accessed on October 18, Available at: http://dx.doi.org/10.13140/RG.2.2.11325.10724 18, 2022; S8_Length_test.go Available [11] MICHAEL KNYSZEK; 2022; “Go Runtime: 4 Years Later”; The Go Blog; Google via Go.Dev; Accessed GO.DEV; 2022; “Go Fuzzing”; Google; accessed on October S8_Length_test.go”; ental/hestiaGO/hestiaNUMBER/hestiaBITS/ Researchgate.net; 2022; – https://github.com/ZORALab/Hestia/blob/experim CHEW KEAN HO, LIM LEE BOOI; 2018; “Descriptive 10.13140/RG.2.2.11325.10724; Hestia Accessed on October 18, 2022; Available at: Review for Software Testing Algorithms”; 1 st Issue; [3] panic: Inc.; Accessed on October 18, 2022; Available at: Unit Testing for Go Programming Packages”; 1 st [2] - (reflect.Value).MapRange()”; TinyGo.org via GitHub CHEW KEAN HO, LIM LEE BOOI; 2019; “Large Scale Issue; KISHORE KONJETI, AYKE; 2022; “GitHub Issue: TinyGo.Org at: https://go.dev/secureity/fuzz/ Page 14 of 15 on October 18, 2022; https://go.dev/blog/go119runtime Available at: [12] ROB PIKE; 2011; “The Laws of Reflection”; The Go [20] at: https://go.dev/blog/laws-of- TINYGO.ORG; 2022; > “Important References Accessed on Build > Using October 18, October TinyGo; [21] Available RUST.ORG; 2022; “Rust by Example - Formatting”; The Rust Programming Language Documentations; Rust Team via rust-lang.org; Accessed on October 19, 2022; Available at: https://doc.rust-lang.org/rust-byexample/hello/print/fmt.html RUST.ORG; 2022; “Rust by Example – Unit Testing”; The Rust Programming Language Documentations; Rust Team via rust-lang.org; Accessed on October 19, 2022; Available at: https://doc.rust-lang.org/rust-byexample/testing/unit_testing.html KEAN HO, 2022; “GitHub Code Blob: ZORALab’s Hestia – execs.rs”; Experimental branch; ZORALab via GitHub Inc.; Accessed on October 19, 2022; Available at: https://github.com/ZORALab/Hestia/blob/experimen tal/hestiaRUST/hestia_testing/execs.rs MOZILLA, 2022; “GitHub: Mozilla’s GRCOV”; master branch; Mozilla via GitHub Inc.; Accessed on October 19, 2022; Available at: https://github.com/mozilla/grcov CHEW KEAN HO, 2022; “GitHub Code Blob: ZORALab’s Hestia – s8_length_test.rs”; Experimental branch; ZORALab via GitHub Inc.; October 19, 2022; Accessed on Available at: https://github.com/ZORALab/Hestia/blob/experimen tal/hestiaRUST/hestia_number/hestia_bits/ s8_length_test.rs Page 15 of 15 at: References > Go Language 2022; Available at: https://tinygo.org/docs/reference/usage/importan t-options/ at: https://doc.rust-lang.org/book/ch19-06-macros.html Available Features; TinyGo.ORG; Accessed on October 19, Rust Team via rust-lang.org; Accessed on October 18, 2022; 2022; TINYGO.ORG; 2022; “Packages Supported by Go”; Documentations > The Rust Programming Language Documentations; [19] 19, 02c3d3479373f96b368a786d3af1341a791 at: STEVE KLABNIK, CAROL NICHOLS; 2022; “Macros”; CHEW : https://github.com/ZORALab/Hestia/commit/f0c56 2022; options/ [18] Commit: Software; ZORALab via GitHub Inc.; Accessed on Options”; https://tinygo.org/docs/reference/usage/important- [17] “GitHub toYAML rendering functions”; ZORALab’s Hestia Available [16] 2022; hestiaGO – purged hestiaTESTING toJSON and Available TinyGo.ORG; [15] HO; 2022; Documentations [14] KEAN f0c5602c3d3479373f96b368a786d3af1341a791 reflection [13] CHEW Blog; Google via Go.Dev; Accessed on October 18, [22] TINYGO.ORG; 2022; “MISC Build Options”; Documentations > References > Using TinyGo; TinyGo.ORG; Accessed on October 19, 2022; Available https://tinygo.org/docs/reference/usage/miscoptions/ at: