{"id":{"repo_id":"colostate","oai_identifier":"oai:mountainscholar.org:10217/66679"},"canonical_url":"https://search.dev.ndltd.org/etd/colostate/oai:mountainscholar.org:10217/66679","repository":{"repo_id":"colostate","name":"Colorado State University","base_url":"https://api.mountainscholar.org/server/oai/request"},"display":{"title":"Random generation of valid object configurations for testing object-oriented programs","abstract":"A unit test case for an object-oriented program typically requires the creation of an object configuration on which the method under test is invoked. Certain approaches, such as RANDOOP, perform feedback-directed random test generation. RANDOOP incrementally generates test cases by only extending the valid ones. Invalid test cases are not explored, and thus, RANDOOP can miss the creation of some valid object configurations. In our approach, we generate a new random object configuration for each test case. This configuration may or may not satisfy the multiplicity constraints in the UML class model of the program. Instead of discarding an invalid configuration, we attempt to fix it and generate a valid test case. Since we do not reject any test case, and do not depend on the feedback from previous test cases, our object configurations are likely to obtain a higher coverage of the domain of valid configurations than RANDOOP. We implemented our approach in a prototype tool called RanTGen, which produces JUnit-style test cases. We also created an Eclipse plugin for RanTGen. Our preliminary results show that RanTGen takes less time than RANDOOP to generate the same number of test cases. RanTGen test cases kill more mutants and achieve higher coverage in terms of statements, branches, and association-end multiplicity (AEM) than RANDOOP test cases. The AEM coverage criterion defines the set of representative multiplicity tuples that must be created during a test, and is used to measure coverage of the domain of valid configurations.","abstract_html":"A unit test case for an object-oriented program typically requires the creation of an object configuration on which the method under test is invoked. Certain approaches, such as RANDOOP, perform feedback-directed random test generation. RANDOOP incrementally generates test cases by only extending the valid ones. Invalid test cases are not explored, and thus, RANDOOP can miss the creation of some valid object configurations. In our approach, we generate a new random object configuration for each test case. This configuration may or may not satisfy the multiplicity constraints in the UML class model of the program. Instead of discarding an invalid configuration, we attempt to fix it and generate a valid test case. Since we do not reject any test case, and do not depend on the feedback from previous test cases, our object configurations are likely to obtain a higher coverage of the domain of valid configurations than RANDOOP. We implemented our approach in a prototype tool called RanTGen, which produces JUnit-style test cases. We also created an Eclipse plugin for RanTGen. Our preliminary results show that RanTGen takes less time than RANDOOP to generate the same number of test cases. RanTGen test cases kill more mutants and achieve higher coverage in terms of statements, branches, and association-end multiplicity (AEM) than RANDOOP test cases. The AEM coverage criterion defines the set of representative multiplicity tuples that must be created during a test, and is used to measure coverage of the domain of valid configurations.","abstract_has_math":false,"creators":["Sadhu, Devadatta, author","Ghosh, Sudipto, advisor","France, Robert, committee member","Turk, Daniel, committee member"],"institution":"Colorado State University. Libraries","degree_name":"Master of Science (M.S.)","degree_level":"Masters","degree_discipline":"Computer Science","degree_department":null,"school":null,"contributors":[],"advisors":[],"committee_chairs":[],"committee_members":[],"year":2012,"date_issued":"2012","date_published":"2012","updated_at":"2026-07-27T19:13:20Z","subjects":["constraints","UML class diagram","random test generation","object configurations","domain coverage"],"languages":["eng","English"],"rights":["Copyright and other restrictions may apply. User is responsible for compliance with all applicable laws. For information about copyright law, please see https://libguides.colostate.edu/copyright."],"rights_urls":[],"identifier_entries":[{"key":"dc:identifier.uri","label":"Identifier URI","values":["https://doi.org/10.25675/3.018934"],"render_values":[{"text":"https://doi.org/10.25675/3.018934","href":"https://doi.org/10.25675/3.018934","code":true}]},{"key":"dc:identifier","label":"Identifier","values":["ETDF2012500098COMS"],"render_values":[{"text":"ETDF2012500098COMS","href":null,"code":true}]}]},"links":{"outbound_url":"http://hdl.handle.net/10217/66679","outbound_label":"Handle","outbound_source":"dc:identifier.uri"},"metadata_groups":[{"id":"people","label":"People","entries":[{"key":"dc:creator","label":"Author","values":["Sadhu, Devadatta, author","Ghosh, Sudipto, advisor","France, Robert, committee member","Turk, Daniel, committee member"]}]},{"id":"academic_context","label":"Academic Context","entries":[{"key":"dc:date.accessioned","label":"Dc Date Accessioned","values":["2007-01-03T08:07:06Z"]},{"key":"dc:date.available","label":"Dc Date Available","values":["2007-01-03T08:07:06Z"]},{"key":"dc:date.issued","label":"Date","values":["2012"]},{"key":"dc:publisher","label":"Institution","values":["Colorado State University. Libraries"]},{"key":"dc:type","label":"Dc Type","values":["Text"]},{"key":"thesis:degree_discipline","label":"Discipline","values":["Computer Science"]},{"key":"thesis:degree_level","label":"Degree Level","values":["Masters"]},{"key":"thesis:degree_name","label":"Degree Name","values":["Master of Science (M.S.)"]},{"key":"thesis:institution_name","label":"Thesis Institution Name","values":["Colorado State University"]}]},{"id":"subjects_keywords","label":"Subjects and Keywords","entries":[{"key":"dc:subject","label":"Dc Subject","values":["constraints","UML class diagram","random test generation","object configurations","domain coverage"]}]},{"id":"language_rights","label":"Language and Rights","entries":[{"key":"dc:language","label":"Dc Language","values":["English"]},{"key":"dc:language.iso","label":"Language (ISO)","values":["eng"]},{"key":"dc:rights","label":"Dc Rights","values":["Copyright and other restrictions may apply. User is responsible for compliance with all applicable laws. For information about copyright law, please see https://libguides.colostate.edu/copyright."]}]},{"id":"identifiers","label":"Identifiers","entries":[{"key":"dc:identifier","label":"Identifier","values":["Sadhu_colostate_0053N_10933.pdf","ETDF2012500098COMS"]},{"key":"dc:identifier.uri","label":"Identifier URI","values":["http://hdl.handle.net/10217/66679","https://doi.org/10.25675/3.018934"]}]},{"id":"additional","label":"Additional Metadata","entries":[{"key":"dc:description.abstract","label":"Abstract","values":["A unit test case for an object-oriented program typically requires the creation of an object configuration on which the method under test is invoked. Certain approaches, such as RANDOOP, perform feedback-directed random test generation. RANDOOP incrementally generates test cases by only extending the valid ones. Invalid test cases are not explored, and thus, RANDOOP can miss the creation of some valid object configurations. In our approach, we generate a new random object configuration for each test case. This configuration may or may not satisfy the multiplicity constraints in the UML class model of the program. Instead of discarding an invalid configuration, we attempt to fix it and generate a valid test case. Since we do not reject any test case, and do not depend on the feedback from previous test cases, our object configurations are likely to obtain a higher coverage of the domain of valid configurations than RANDOOP. We implemented our approach in a prototype tool called RanTGen, which produces JUnit-style test cases. We also created an Eclipse plugin for RanTGen. Our preliminary results show that RanTGen takes less time than RANDOOP to generate the same number of test cases. RanTGen test cases kill more mutants and achieve higher coverage in terms of statements, branches, and association-end multiplicity (AEM) than RANDOOP test cases. The AEM coverage criterion defines the set of representative multiplicity tuples that must be created during a test, and is used to measure coverage of the domain of valid configurations."]},{"key":"dc:format.medium","label":"Dc Format Medium","values":["born digital","masters theses"]},{"key":"dc:title","label":"Title","values":["Random generation of valid object configurations for testing object-oriented programs"]}]}],"canonical_facts":{"dc:creator":["Sadhu, Devadatta, author","Ghosh, Sudipto, advisor","France, Robert, committee member","Turk, Daniel, committee member"],"dc:date.accessioned":["2007-01-03T08:07:06Z"],"dc:date.available":["2007-01-03T08:07:06Z"],"dc:date.issued":["2012"],"dc:description.abstract":["A unit test case for an object-oriented program typically requires the creation of an object configuration on which the method under test is invoked. Certain approaches, such as RANDOOP, perform feedback-directed random test generation. RANDOOP incrementally generates test cases by only extending the valid ones. Invalid test cases are not explored, and thus, RANDOOP can miss the creation of some valid object configurations. In our approach, we generate a new random object configuration for each test case. This configuration may or may not satisfy the multiplicity constraints in the UML class model of the program. Instead of discarding an invalid configuration, we attempt to fix it and generate a valid test case. Since we do not reject any test case, and do not depend on the feedback from previous test cases, our object configurations are likely to obtain a higher coverage of the domain of valid configurations than RANDOOP. We implemented our approach in a prototype tool called RanTGen, which produces JUnit-style test cases. We also created an Eclipse plugin for RanTGen. Our preliminary results show that RanTGen takes less time than RANDOOP to generate the same number of test cases. RanTGen test cases kill more mutants and achieve higher coverage in terms of statements, branches, and association-end multiplicity (AEM) than RANDOOP test cases. The AEM coverage criterion defines the set of representative multiplicity tuples that must be created during a test, and is used to measure coverage of the domain of valid configurations."],"dc:format.medium":["born digital","masters theses"],"dc:identifier":["Sadhu_colostate_0053N_10933.pdf","ETDF2012500098COMS"],"dc:identifier.uri":["http://hdl.handle.net/10217/66679","https://doi.org/10.25675/3.018934"],"dc:language":["English"],"dc:language.iso":["eng"],"dc:publisher":["Colorado State University. Libraries"],"dc:rights":["Copyright and other restrictions may apply. User is responsible for compliance with all applicable laws. For information about copyright law, please see https://libguides.colostate.edu/copyright."],"dc:subject":["constraints","UML class diagram","random test generation","object configurations","domain coverage"],"dc:title":["Random generation of valid object configurations for testing object-oriented programs"],"dc:type":["Text"],"thesis:degree_discipline":["Computer Science"],"thesis:degree_level":["Masters"],"thesis:degree_name":["Master of Science (M.S.)"],"thesis:institution_name":["Colorado State University"]},"updated_at":"2026-07-27T19:13:20Z"}