Find research datasets worth reusing
Search datasets from major research repositories and use ShareScore to quickly assess how well each record supports discovery, access, and reuse.
144
datasets available to search
ShareScore release 0.9.0
Dataset results
144 results for “Test Generation”
Testing absolute plate reference frames and the implications for the generation of geodynamic mantle heterogeneity structure
<div>Description of Resources - Shephard et al. (2012)</div> <div> </div> <div>This file provides a detailed description of all of the files that make up the data collection associated with the publication: Shephard, G. E., Bunge, H. P., Schuberth, B. S., Müller, R. D., Talsma, A. S., Moder, C., & Landgrebe, T. C. W. (2012). Testing absolute plate reference frames and the implications for the generation of geodynamic mantle heterogeneity structure. Earth and Planetary Science Letters, 317, 204-217. doi: <a href="https://doi.org/10.1016/j.epsl.2011.11.027" target="_blank" rel="noopener">10.1016/j.epsl.2011.11.027</a></div> <div> </div> <div>Note: For information on file formats and what programs to use to interact with various file formats, see "File Formats and Recommended Programs”.</div> <div> </div> <div>This data collection includes both the rotations and topologically closed polygons* for each of the 5 absolute reference frames that were tested in the publication. They are to be loaded in GPlates (<a href="http://www.gplates.org" target="_blank" rel="noopener">http://www.gplates.org</a>).</div> <div> </div> <div>*Topologically closed plate polygons are constructed from the intersection of ridges, transforms, subduction zones and other plate boundary geometries. These 'resolved topologies' are valid at 1 Myr intervals. The plate boundary geometries and plate polygons have been assigned plate reconstruction IDs to allow them to be reconstructed using the supplied rotation files. </div> <div> </div> <div>The files associated with this data collection include:</div> <div>• <strong>Hybrid hotspot model (Moving and Fixed hotspots) (HHS)</strong></div> <div>* Caltech_Global_20110311HHS.gpml (37 MB) - topologically closed plate polygons and plate boundary geometries</div> <div>* Caltech_Global_20110412HHS.rot (287 KB)- global rotation model</div> <div> </div> <div>• <strong>Fixed hotspot model (FHS)</strong></div> <div>* Caltech_Global_20110311FHS.gpml (36.8 MB) - topologically closed plate polygons and plate boundary geometries</div> <div>* Caltech_Global_20110412FHS.rot (291 KB) - global rotation model</div> <div> </div> <div>•<strong> Hybrid hotspot and palaeomagnetic model (PMG)</strong></div> <div>* Caltech_Global_20110311PMG.gpml (35.9 MB) - topologically closed plate polygons and plate boundary geometries</div> <div>* Caltech_Global_20110412PMG.rot (287 KB) - global rotation model</div> <div> </div> <div>• <strong>Subduction reference frame model (SUB)</strong></div> <div>* Caltech_Global_20110311SUB.gpml (36 MB) - topologically closed plate polygons and plate boundary geometries</div> <div>* Caltech_Global_20110412SUB.rot (287 KB) - global rotation model</div> <div> </div> <div>• <strong>Hybrid hotspot and TPW-corrected palaeomagnetic model (TPW)</strong></div> <div>* Caltech_Global_20110311TPW.gpml (36.8 MB) - topologically closed plate polygons and plate boundary geometries</div> <div>* Caltech_Global_20110412TPW.rot (287 KB)- global rotation model</div> <div> </div> <div>Project files (.gproj) are included for each .gpml/.rot pair.</div> <div> </div> <div>This article has additional supplementary data available with the online publication.</div> <div> </div> <div> </div> <div>Additional notes:</div> <div>*.rot contains the rotations for all plates and topological polygons.</div> <div>Each model is specific according to the African Plate (Plate ID 701) rotations. The rotations for all other plates are the same across each of the five models with the exception of cross-overs involving Pacific/Panthalassa plates for times earlier than 83.5Ma; these must be absolute reference frame specific and were re-calculated for each model. Programs used to calculate the new finite rotations include "adder" and "seaflow" </div> <div> </div> <div>*.gpml and .shp files contain continuously closing plate polygons i.e. from plate boundaries, from 140 Ma to present-day in 1 million year increments. </div> <div>These files differ slightly from those used in the paper, but are the most up-to-date version (as at May 2011) and are based on an updated model, Seton et al. (2012).</div> <div>They are specific to each of the five absolute reference frames. </div> <div> </div> <div>Note on velocity calculations in GPlates:</div> <div>GPlates calculates the velocity within each plate based on the stage rotation for that time period and averages for that respective period. For this reason, the velocities of a plate do not change incrementally within the time period and then abruptly change according to the next time period/stage rotation. </div> <div>This is also why there appears to be a "jump" in velocity magnitude and direction between 140 and 139 Ma.</div>
Workplans generated during AWOPS tests
<p>The dataset is about workplans generated during the validation of the Automated Work Planning Services (AWOPS).The dataset includes:</p> <ul> <li>9 xml files regarding workplans automatically generated by AWOPS for renovation works' activities during the following days: <ul> <li>March 7<sup>th</sup> 2022 (day 0);</li> <li>March 14<sup>th</sup> 2022 (day 2);</li> <li>March 17<sup>th</sup> 2022 (day 5);</li> <li>March 21<sup>st</sup> 2022 (day 9);</li> <li>March 24<sup>th</sup> 2022 (day 12);</li> <li>March 28<sup>th</sup> 2022 (day 16);</li> <li>March 31<sup>st</sup> 2022 (day 19);</li> <li>April 4<sup>th</sup> 2022 (day 23);</li> <li>April 7<sup>th</sup> 2022 (day 26).</li> </ul> </li> </ul>
LLM generated Python Compiler Test Dataset
<p>This dataset is generated by integrating Large Language Models (LLMs) with AFL++ fuzzing to enhance compiler testing for CPython. It includes original Python test scripts created by LLMs such as Mistral 7B, Codellama 7B, and Gemma 7B, targeted at various compiler functionalities. These scripts were subjected to fuzzing, resulting in a rich collection of test cases that tests potential vulnerabilities. An optional minimization process with AFL-cmin refined the dataset, ensuring it focuses on test cases that significantly contribute to code coverage and bug discovery. This dataset serves as a valuable resource for improving compiler design and testing efficiency, supporting further research and development in AI-driven software testing methods.</p> <p>please see references for citations of software used in this development</p>
Evaluation Data of the Implementation of the Approach for Automatic Test Generation for Information-Flow Properties
<p>This data set contains the programs for which the automatic test generation approach of the KeY theorem prover was used to automatically generate noninterference tests.</p> <p>The approach is described in <a href="http://dx.doi.org/10.1145/3297280.3297500 ">http://dx.doi.org/10.1145/3297280.3297500 </a></p> <p>DATA<br> ---------<br> The data folder contains the secure and insecure programs which were evaluated and the tests which were generated for them.</p> <p>Each program is in the folder "program" and is written in Java and specified in an extended version of the JML specification language. Check out <a href="http://dx.doi.org/10.5445/IR/1000046878">http://dx.doi.org/10.5445/IR/1000046878</a> for a reference on the used specification language.</p> <p>For each example we provide the tests that were generated. For the insecure examples we provide the tests generated with each of the two options of our approach. The tests generated with the option for searching for counterexamples is in the folder "WithPost" of each insecure example.</p> <p> </p>
Diversity-Driven Unit Test Generation (Data Set)
<p>The goal of automated unit test generation tools is to create a set of test cases for the software under test that achieve the highest possible coverage for the selected test quality criteria. The most effective approaches for achieving this goal at the present time use meta-heuristic optimization algorithms to search for new test cases using fitness functions defined on existing sets of test<br> cases and the system under test. Regardless of how their search algorithms are controlled, however, all existing approaches focus on the analysis of exactly one implementation, the software under test, to drive their search processes, which is a limitation on the information they have available. In this paper we investigate whether the practical effectiveness of white box unit test generation tools can be increased by giving them access to multiple, diverse implementations of the functionality under test harvested from widely available Open Source software repositories. After presenting a basic implementation of such an approach, DivGen (Diversity-driven Generation), on top of the leading test generation tool for Java (EvoSuite), we assess the performance of DivGen compared to EvoSuite when applied in its traditional, mono-implementation oriented mode (MonoGen). The results show that while DivGen outperforms MonoGen in 33% of the sampled classes for mutation coverage (+16% higher on average), MonoGen outperforms<br> DivGen in 12.4% of the classes for branch coverage (+10% higher average).</p>
Test Suites from Test-Generation Tools (Test-Comp 2019)
<p>This file describes the contents of an archive of the<br> 1st Competition on Software Testing (Test-Comp 2019)<br> <a href="https://test-comp.sosy-lab.org/2019/">https://test-comp.sosy-lab.org/2019/</a></p> <p>The competition was run by Dirk Beyer, LMU Munich, Germany.<br> More information is available in the following article:<br> Dirk Beyer. First International Competition on Software Testing: Test-Comp 2019.<br> International Journal on Software Tools for Technology Transfer, 2020.</p> <p>Copyright (C) Dirk Beyer<br> <a href="https://www.sosy-lab.org/people/beyer/">https://www.sosy-lab.org/people/beyer/</a></p> <p>SPDX-License-Identifier: CC-BY-4.0<br> <a href="https://spdx.org/licenses/CC-BY-4.0.html">https://spdx.org/licenses/CC-BY-4.0.html</a></p> <p> </p> <p>Contents:</p> <p>LICENSE.txt specifies the license<br> README.txt this file<br> witnessFileByHash/ This directory contains test suites (witnesses for coverage).<br> Each witness in this directory is stored in a file whose name is the SHA2 256-bit hash<br> of its contents followed by the filename extension .zip.<br> The format of each test suite is described on the format web page:<br> https://gitlab.com/sosy-lab/software/test-format<br> A test suite contains also metadata in order to relate it<br> to the test problem for which it was produced.<br> witnessInfoByHash/ This directory contains for each test suite (witness) in directory witnessFileByHash/<br> a record in JSON format (also using the SHA2 256-bit hash of the witness as filename,<br> with .json as filename extension) that contains the meta data.<br> witnessListByProgramHashJSON/<br> For convenient access to all test suites for a certain program, this directory represents<br> a function that maps each program (via its SHA2 256-bit hash) to a set of test suites<br> (JSON records for test suites as described above) that the test tools have produced<br> for that program. For each program for which test suites exist, the directory contains<br> a JSON file (using the SHA2 256-bit hash of the program as filename, with .json as<br> filename extension) that contains all JSON records for test suites for that program.</p> <p>A similar data structure was used by SV-COMP and is described in the following article:<br> Dirk Beyer. A Data Set of Program Invariants and Error Paths.<br> In Proceedings of the 2019 IEEE/ACM 16th International Conference on Mining Software Repositories<br> (MSR 2019, Montreal, Canada, May 26-27), pages 111-115, 2019. IEEE.<br> <a href="https://doi.org/10.1109/MSR.2019.00026">https://doi.org/10.1109/MSR.2019.00026</a></p> <p> </p> <p>Overview over archives from Test-Comp 2019 that are available at Zenodo:</p> <p><a href="https://doi.org/10.5281/zenodo.3856669">https://doi.org/10.5281/zenodo.3856669</a> Witness store (containing the generated test suites)<br> <a href="https://doi.org/10.5281/zenodo.3856661">https://doi.org/10.5281/zenodo.3856661</a> Results (XML result files, log files, file mappings, HTML tables)<br> <a href="https://doi.org/10.5281/zenodo.3856478">https://doi.org/10.5281/zenodo.3856478</a> Test tasks, version testcomp19<br> <a href="https://doi.org/10.5281/zenodo.2561835">https://doi.org/10.5281/zenodo.2561835</a> BenchExec, version 1.18</p> <p>All benchmarks were executed<br> for Test-Comp 2019, <a href="https://test-comp.sosy-lab.org/2019/">https://test-comp.sosy-lab.org/2019/</a><br> by Dirk Beyer, LMU Munich<br> based on the components<br> git@github.com:sosy-lab/sv-benchmarks.git testcomp19-0-g6a770a9c1<br> git@gitlab.com:sosy-lab/test-comp/bench-defs.git testcomp19-0-g1677027<br> git@github.com:sosy-lab/benchexec.git 1.18-0-gff72868</p> <p><br> Feel free to contact me in case of questions:<br> <a href="https://www.sosy-lab.org/people/beyer/">https://www.sosy-lab.org/people/beyer/</a></p> <p> </p>
Replication package of "Revisiting Test Smells in Automatically Generated Tests: Limitations, Pitfalls, and Opportunities"
<p><strong>Abstract:</strong><br> Test smells attempt to capture design issues in test code that reduce their maintainability. Previous work found such smells to be highly common in automatically generated test-cases, but based this result on specific static detection rules; although these are based on the original definition of “test smells”, a recent empirical study showed that developers perceive these as overly strict and non-representative of the maintainability and quality of test suites. This leads us to investigate how effective such test smell detection tools are on automatically generated test suites. In this paper, we build a dataset of 2,340 test cases automatically generated by EVOSUITE for 100 Java classes. We performed a multi-stage, cross-validated manual analysis to identify six types of test smells and label their instances. We benchmark the performance of two test smell detection tools: one widely used in prior work, and one recently introduced with the express goal to match developer perceptions of test smells. Our results show that these test smell detection strategies poorly characterized the issues in automatically generated test suites; the older tool’s detection strategies, especially, misclassified over 70% of test smells, both missing real instances (false negatives) and marking many smell-free tests as smelly (false positives). We identify common patterns in these tests that can be used to improve the tools, refine and update the definition of certain test smells, and highlight as of yet uncharacterized issues. Our findings suggest the need for (i) more appropriate metrics to match development practice; and (ii) more accurate detection strategies, to be evaluated primarily in industrial contexts.</p>
Test Suites from Test-Generation Tools (Test-Comp 2021)
<p>Test Suites</p> <p>This file describes the contents of an archive of the 3rd Competition on Software Testing (Test-Comp 2021).<br> <a href="https://test-comp.sosy-lab.org/2021/">https://test-comp.sosy-lab.org/2021/</a></p> <p>The competition was run by Dirk Beyer, LMU Munich, Germany.<br> More information is available in the following article:<br> Dirk Beyer. <em>Status Report on Software Testing: Test-Comp 2021.</em> In Proceedings of the 24th International Conference on Fundamental Approaches to Software Engineering (FASE 2021, Luxembourg, March 27 - April 1), 2021. Springer.</p> <p>Copyright (C) Dirk Beyer<br> <a href="https://www.sosy-lab.org/people/beyer/">https://www.sosy-lab.org/people/beyer/</a></p> <p>SPDX-License-Identifier: CC-BY-4.0<br> <a href="https://spdx.org/licenses/CC-BY-4.0.html">https://spdx.org/licenses/CC-BY-4.0.html</a></p> <p>Contents</p> <ul> <li><code>LICENSE.txt</code>: specifies the license</li> <li><code>README.txt</code>: this file</li> <li><code>witnessFileByHash/</code>: This directory contains test suites (witnesses for coverage). Each witness in this directory is stored in a file whose name is the SHA2 256-bit hash of its contents followed by the filename extension .zip. The format of each test suite is described on the format web page: <a href="https://gitlab.com/sosy-lab/software/test-format">https://gitlab.com/sosy-lab/software/test-format</a> A test suite contains also metadata in order to relate it to the test problem for which it was produced.</li> <li><code>witnessInfoByHash/</code>: This directory contains for each test suite (witness) in directory witnessFileByHash/ a record in JSON format (also using the SHA2 256-bit hash of the witness as filename, with .json as filename extension) that contains the meta data.</li> <li><code>witnessListByProgramHashJSON/</code>: For convenient access to all test suites for a certain program, this directory represents a function that maps each program (via its SHA2256-bit hash) to a set of test suites (JSON records for test suites as described above) that the test tools have produced for that program. For each program for which test suites exist, the directory contains a JSON file (using the SHA2 256-bit hash of the program as filename, with .json as filename extension) that contains all JSON records for test suites for that program.</li> </ul> <p>A similar data structure was used by SV-COMP and is described in the following article:<br> Dirk Beyer. <em>A Data Set of Program Invariants and Error Paths.</em> In Proceedings of the 2019 IEEE/ACM 16th International Conference on Mining Software Repositories (MSR 2019, Montreal, Canada, May 26-27), pages 111-115, 2019. IEEE.<br> <a href="https://doi.org/10.1109/MSR.2019.00026">https://doi.org/10.1109/MSR.2019.00026</a></p> <p>Other Archives</p> <p>Overview over archives from Test-Comp 2021 that are available at Zenodo:</p> <ul> <li><a href="https://doi.org/10.5281/zenodo.4459466">https://doi.org/10.5281/zenodo.4459466</a> Witness store (containing the generated test suites)</li> <li><a href="https://doi.org/10.5281/zenodo.4459470">https://doi.org/10.5281/zenodo.4459470</a> Results (XML result files, log files, file mappings, HTML tables)</li> <li><a href="https://doi.org/10.5281/zenodo.4459132">https://doi.org/10.5281/zenodo.4459132</a> Test tasks, version testcomp21</li> <li><a href="https://doi.org/10.5281/zenodo.4317433">https://doi.org/10.5281/zenodo.4317433</a> BenchExec, version 3.6</li> </ul> <p>All benchmarks were executed for Test-Comp 2021 <a href="https://test-comp.sosy-lab.org/2021/">https://test-comp.sosy-lab.org/2021/</a><br> by Dirk Beyer, LMU Munich, based on the following components:</p> <ul> <li><a href="https://gitlab.com/sosy-lab/test-comp/archives-2021">https://gitlab.com/sosy-lab/test-comp/archives-2021</a> testcomp21-0-gdacd4bf</li> <li><a href="https://gitlab.com/sosy-lab/software/sv-benchmarks">https://gitlab.com/sosy-lab/software/sv-benchmarks</a> testcomp21-0-gefea738258</li> <li><a href="https://gitlab.com/sosy-lab/software/benchexec">https://gitlab.com/sosy-lab/software/benchexec</a> 3.6-0-gb278ebbb</li> <li><a href="https://gitlab.com/sosy-lab/benchmarking/competition-scripts">https://gitlab.com/sosy-lab/benchmarking/competition-scripts</a> testcomp21-0-g8339740</li> <li><a href="https://gitlab.com/sosy-lab/test-comp/bench-defs">https://gitlab.com/sosy-lab/test-comp/bench-defs</a> testcomp21-0-g9d532c9</li> </ul> <p>Contact</p> <p>Feel free to contact me in case of questions: <a href="https://www.sosy-lab.org/people/beyer/">https://www.sosy-lab.org/people/beyer/</a></p>
Genotype reproducibility testing in next-generation sequencing data
<p>Code, log and results summary for testing the reproducibility of genotypes with three pairs of hemiclones in the Sussex LH<sub>M </sub><em>D.melanogaster </em>population sample. Discovery and genotyping of genomic sequence variants was done using GATK HaplotypeCaller, and Genomestrip. Numerical comparison of genotype calls within each pairs of hemiclone individuals was performed using GATK GenotypeConcordance.</p> <p> </p> <p>The pre-print manuscript for this data is available on biorxiv: "Whole genome resequencing of a laboratory-adapted Drosophila melanogaster population sample" http://biorxiv.org/content/early/2016/10/17/081554 doi: http://dx.doi.org/10.1101/081554</p>
Test Data Generation from Business Rules
<p><strong>Overview of Data</strong></p> <p>The site includes data only for the two subjects: Ceu-pacific and JBilling. For both the subjects, the “<em>.model” shows the model created from the business rules obtained from respective websites, and “</em>_HighLevelTests.csv” shows the tests generated. Among csv files, we show tests generated by both BUSTER and Exhaust as well.</p> <p><strong>Paper Abstract</strong></p> <p>Test cases that drive an application under test via its graphical user interface (GUI) consist of sequences of steps that perform actions on, or verify the state of, the application user interface. Such tests can be hard to maintain, especially if they are not properly modularized—that is, common steps occur in many test cases, which can make test maintenance cumbersome and expensive. Performing modularization manually can take up considerable human effort. To address this, we present an automated approach for modularizing GUI test cases. Our approach consists of multiple phases. In the first phase, it analyzes individual test cases to partition test steps into candidate subroutines, based on how user-interface elements are accessed in the steps. This phase can analyze the test cases only or also leverage execution traces of the tests, which involves a cost-accuracy tradeoff. In the second phase, the technique compares candidate subroutines across test cases, and refines them to compute the final set of subroutines. In the last phase, it creates callable subroutines, with parameterized data and control flow, and refactors the original tests to call the subroutines with context-specific data and control parameters. Our empirical results, collected using open-source applications, illustrate the effectiveness of the approach.</p>
BRAIN Journal-High Performance Data mining by Genetic Neural Network-Figure 7 . Test Accuracy with prograess generation
<p>In the training phase, the neural network weights errors are minimized and network design<br> problem which the objective function to an acceptable level. In test step we have better results<br> because weights of neural network are adjusted by genetic algorithm and back propagation method.<br> Of course achievement to accuracy with 83.5% is reason using of good feature with minimum error.</p>
BRAIN Journal-Auto-generative Learning Objects in Online Assessment of Data Structures Disciplines-Figure 3. Symbols definition for a graph-based test
<p>In this scenario, we intend to generate a random graph and compute a deep first-search node list. The first defined random symbol is n, namely the number of nodes in the graph as an integer from 5 to 9. The next symbol is named g and denotes the graph object created randomly using 3 parameters: the number of nodes, the minimum, and the maximum value for the weight. For the number of nodes, we used the previously computed value of n, whereas for the weights, we used two constants 0 and 1 since the graph is not weighted</p>
BRAIN Journal-Auto-generative Learning Objects in Online Assessment of Data Structures Disciplines-Figure 4. Online test assessment example
<p>Thus, applying these restrictions the computed solution is C, E, G, J, L, H, I and is unique. Node C is the starting node since it is the first from the lexicographical point of view. The first step CE is the only choice coping with the restrictions from the [CE, CG, and CJ] edges. Next, EG is the first edge in the list of [EG, EJ]. The next step is GJ which is the only choice. Edge JL is another unique choice. Edge LH is the next step from the list [LH, LI]. Finally, the last edge is obtained by backtracking to node L and then taking edge LI. These restrictions allow us to drive the student to build only one solution from the possible set of solutions. This will determine an easier way of comparing the student’s answer with the answer of the computer. Another more general solution is to use validation functions which require implementation in domain libraries written in JavaScript. </p>
Data Set Used in Combinatorial Modeling and Test Case Generation for Industrial Control Software using ACTS
<p>This document contains the data set used for the study Combinatorial Modeling and Test Case Generation for Industrial Control Software using ACTS that is currently in submission.</p>
Generated Software Testing Workload
<p>This dataset represents a software testing workload generated from the distributions characterizing a real software testing workload. It consists of instance files, each of which is structured as follows:</p> <pre><code>[number of test suites] [test suite uuid] [test suite priority (1>0)] [arrival time (s)] [number of test cases] [test case uuid] [test case type] [test case outcome (0 - pass)] [test case duration (s)] [test case uuid] [test case type] [test case outcome (0 - pass)] [test case duration (s)] (...) [test suite uuid] [test suite priority (1>0)] [arrival time (s)] [number of test cases] [test case uuid] [test case type] [test case outcome (0 - pass)] [test case duration (s)] [test case uuid] [test case type] [test case outcome (0 - pass)] [test case duration (s)] (...) (...)</code></pre> <p> </p>
ViSAPy-generated test data from Lee JH., et al. Advances in Neural Information Processing Systems 30 (NIPS 2017), pp4002--4012
<p>This dataset corresponds to the simulated test data for spike-sorting algorithms in Figure 3 of:</p> <p>Lee, Jin Hyung and Carlson, David E and Shokri Razaghi, Hooshmand and Yao, Weichi and Goetz, Georges A and Hagen, Espen and Batty, Eleanor and Chichilnisky, E.J. and Einevoll, Gaute T. and Paninski, Liam. YASS: Yet Another Spike Sorter. Advances in Neural Information Processing Systems 30 (NIPS 2017). Editors I. Guyon and U. V. Luxburg and S. Bengio and H. Wallach and R. Fergus and S. Vishwanathan and R. Garnett, year 2017, pp4002-4012.<br> publisher: Curran Associates, Inc. URL http://papers.nips.cc/paper/6989-yass-yet-another-spike-sorter.pdf</p>
Online Appendix - Scented Since the Beginning: On the Diffuseness of Test Smells in Automatically Generated Test Code
<p>Online appendix for the paper "Scented Since the Beginning: On the Diffuseness of Test Smells in Automatically Generated Test Code".</p> <p>The full description of the content of this appendix can be found in the README file.</p>
Learning How to Search: Generating Effective Test Cases Through Adaptive Fitness Function Selection
<p>Data Package for "Learning How to Search: Generating Effective Test Cases Through Adaptive Fitness Function Selection"</p> <p>This package contains data generated as part of our experiments on adaptive fitness function selection as part of unit test generation for Java systems.</p> <p>This paper is currently under submission. A draft of the paper is included in the data package.</p> <p>This package contains experimental data (in folder "experiment_data"), including goal attainment, fault detection, time per generation, and choices made by the reinforcement learning algorithm. In the folder "test_suites", the suites generated by each technique are included for each project. </p> <p>If you have questions, please contact Gregory Gay at greg@greggay.com.</p> <p>NOTE: A small number of items are currently missing from this data package and will be added shortly. Please make sure you have the latest version of this package.</p>
Developer-Centric Test Amplification: The Interplay Between Automatic Generation and Human Exploration --- Appendix
<p>This online appendix contains the accumulated code occurences during the interviews performed to evaluate our developer-centric test amplification approach and the TestCube plugin. In addition, it documents the inter-rater-reliability analysis we performed.</p>
Choosing the Right Test Generation Tool: A Guide for Software Practitioners
<p> Context: As software systems become increasingly complex, testing automation plays a critical role in ensuring product quality and reliability. However, the wide variety of available test generation tools—with distinct purposes, features, and approaches—makes it difficult for practitioners to select the most appropriate option for their projects. Goal: This study aims to identify, analyze, and compare test generation tools reported in both academic and industrial contexts, providing a practical reference guide to support software professionals in tool selection decisions. Method: We conducted a Multivocal Literature Review (MLR) complemented by a two-round survey with 87 software practitioners. The MLR identified tools and features reported in white and gray literature, while the survey assessed practitioners’ familiarity, usage, and perceptions of advantages and challenges associated with these tools. Results: The findings reveal a persistent gap between academic proposals and industrial adoption. While tools such as Postman, Selenium, and Cypress are among the most widely used tools in practice, academic tools like Monkey and Dynodroid remain rarely adopted. Practitioners value visibility, integration, and traceability as key features, whereas inconsistency and maintenance effort are seen as primary challenges. Conclusions: The study contributes a structured reference guide to assist professionals in selecting tools suitable for specific testing contexts. It also provides insights for researchers aiming to align future tool development with industry needs, fostering better usability, integration, and sustainability of automated testing solutions.</p>
ScienceDex guides
Understand access before you commit
These curated guides explain access requirements, typical timelines, costs, and reuse considerations for widely used research datasets.
Allen Brain Atlas
Allen Brain Atlas is an Allen Institute collection of brain map atlases, datasets, APIs, and analysis tools covering mouse, human, and non-human primate brain resources.
Annotated Behaviour and Observability Dataset (ABODe)
ABODe is a University of Edinburgh DataShare dataset for behavior classification in group-housed mice using home-cage video, identities, bounding boxes, ground-plate positions, and annotator labels.
DANDI Archive for NWB datasets
DANDI is a BRAIN Initiative archive for publishing and sharing neurophysiology data, including electrophysiology, optophysiology, and behavioral data packaged as NWB and related standards.
International Brain Laboratory public data
The International Brain Laboratory public data releases expose standardized mouse decision-making experiments, including Neuropixels recordings, widefield calcium imaging, behavior, and session metadata accessed through the ONE API.
OpenNeuro
OpenNeuro is a free, open platform for sharing neuroimaging datasets, with public search, dataset pages, and download paths for web, S3, DataLad, and the OpenNeuro CLI.