Patent Issued for Software testing in parallel threads with a record-locking database (USPTO 11537508): State Farm Mutual Automobile Insurance Company
2023 JAN 18 (NewsRx) -- By a
The patent’s assignee for patent number 11537508 is
News editors obtained the following quote from the background information supplied by the inventors: “During development of a software application, software developers can prepare tests to verify that the software application operates as expected. Such tests may be associated with unit testing that tests the functionality of a relatively small piece of code, and/or integration testing that tests how multiple pieces of code interact. Because individual tests may be designed to test one or more relatively small aspects of the overall software application, software developers may create numerous tests associated with the entire software application.
“Some tests associated with the software application may build on one another. For instance, a first test may create a record in a database, and a second test may be designed to further access or edit the database record created by the first test. In this situation, a developer may write code for the second test under the assumption that the first test will already have executed and created the record in the database by the time the second test executes. Accordingly, in this situation, the second test may be dependent on data created by the first test.
“In some situations, when a new version of the software application is tested, it can take a relatively long period of time to execute all of the tests and verify that the new version of the software application successfully passes all of the tests. For instance, tests can be written to build on each other in a sequential order as discussed above, and running a large set of tests in a sequence can take a relatively long period of time. As a non-limiting example, tests for a software application may be written in a set of 7000 class files that each include numerous functions, and it may take up to two hours to sequentially execute all of the tests in the 7000 class files.
“The time it takes to sequentially execute a large set of tests can pose challenges and introduce delays during software development, particularly in situations in which multiple developers are working on the same software application. As an example, a team of software developers may generate sixty new builds of the software application in a single day. If each build is tested using a set of 7000 class files that takes up to 120 minutes of server time to execute, the testing may take up to 7200 minutes of server time in a single day.
“As another example, two developers may check out code from a main code branch and independently make changes to the code for the software application. If the first developer submits updated code for testing, it may take two hours to run a full set of test cases on the first developer’s updated code. However, by the time the testing verifies that the first developer’s changes have passed the full set of test cases and can be incorporated back into the main code branch, the second developer may separately have submitted different code changes for testing. The code changes made by the second developer may be incompatible with the changes made by the first developer. Accordingly, even if the second developer’s changes also independently pass the full set of test cases, it may not be possible to incorporate those changes back into the main code branch due to incompatible changes already made by the first developer. If testing of the first developer’s code changes had been performed more quickly, the second developer could have been made aware of the first developer’s changes and accounted for them before the second developer submitted additional code changes for testing.
“Accordingly, it can be desirable to run a full set of tests on updated code for a software application more quickly than described above. One possibility for speeding up the testing process is to run different tests in parallel at the same time. For example, rather than running tests within a full set of 7000 class files in sequence, the tests can be divided into smaller sets that can be run simultaneously in two or more parallel threads. Although executing the full set of tests in sequence may take up to two hours, running different subsets of the tests simultaneously in parallel threads may allow the full set of tests to complete in 30 minutes or less. Developers can thus be notified whether their code changes pass the full set of tests more quickly, and allow code changes that have passed the full set of tests to be merged into a main code branch more quickly. In addition to executing a full set of tests more quickly for a single new build of a software application, running tests in parallel threads can also reduce overall usage of server time when multiple new builds of the software application are tested. For instance, if testing each build of a software application takes up to 120 minutes when tests are executed sequentially in a single thread, it can take up to 7200 minutes of server time to test sixty different builds in a day. If running the tests in parallel reduces the testing time for each build down to 30 minutes as discussed above, testing sixty builds in a day may instead take only 1800 minutes of server time. However, although executing tests in parallel can speed up testing of a software application, in some cases the parallelization itself can cause errors and/or failed tests during testing.
“For example, as discussed above, tests may be written under the assumption that the tests will build on one another in a sequential order. Code changes may pass such tests if the tests are indeed executed sequentially in the originally-intended order. However, the same code changes may not pass the same tests if the tests are executed out of order, for instance because related or dependent tests are executed out of order in different parallel threads.
“As an example, multiple tests may attempt to access the same table of a database. The database may be configured to at least briefly lock the table when the table is accessed by a code element, such that the database table cannot be changed by other code elements while the table is locked. If a set of tests are run sequentially in an intended order, a first test may have finished accessing a database table, and the table can thus be unlocked, by the time a second test later attempts to access the database table. The second test may succeed in this scenario due to the unlocked database table. However, if the tests are instead run in parallel as described above, there is a chance that different tests, executing simultaneously in different parallel threads, may attempt to access the same database table at essentially the same time. This can cause database conflicts, table locking errors, and/or failure of one or more of the tests. For instance, if a database table is locked due to a first test accessing the database table, the table may still be locked if a second test, executing in parallel with the first test, also attempts to access the database table. The database table locking can thus cause the second test to fail, even though the second test may have succeeded if it had been executed at a different time when the database table was not locked due to another test executing in parallel.
“The example systems and methods described herein may be directed toward mitigating or overcoming one or more of the deficiencies described above.”
As a supplement to the background information on this patent, NewsRx correspondents also obtained the inventors’ summary information for this patent: “Described herein are systems and methods for testing a software application using a set of test cases distributed among parallel threads, in association with a record-locking database. To avoid database conflicts that may occur when different test cases in different parallel threads attempt to access the same database simultaneously, testing of the software application can be performed in association with a record-locking database that locks database records individually instead of, for example, locking entire database tables. Locking individual database records, instead of entire database tables or other larger database elements, can reduce and/or eliminate the chances that a test case in one parallel thread will be unable to access a record in the database because another test case in another parallel thread is simultaneously accessing the same database table or larger database element.
“According to a first aspect, a computer-implemented method can include instantiating, by one or more processors of a computing device, a record-locking database associated with a software application. The method can also include identifying, by the one or more processors, a plurality of test cases associated with the software application, and distributing, by the one or more processors, individual test cases of the plurality of test cases among a plurality of test sets. The different test sets of the plurality of test sets can be configured to execute simultaneously in different parallel threads on the computing device. The method can further include locking, by the one or more processors, a first record in the record-locking database based on an access attempt by a first test case executing via a first parallel thread. The method can also include granting, by the one or more processors, a second test case access to a second record in the record-locking database while the first record is locked, wherein the second test case executes, via a second parallel thread, substantially simultaneously with the first test case executing via the first parallel thread.
“According to a second aspect, a computing device can include one or more processors and memory storing computer-executable instructions that, when executed by the one or more processors, cause the one or more processors to perform operations. The operations can include instantiating a record-locking database associated with a software application, identifying a plurality of test cases associated with the software application, and distributing individual test cases of the plurality of test cases among a plurality of test sets. The plurality of test sets can correspond to a plurality of parallel threads. The operations can further include simultaneously executing the plurality of test sets via the plurality of parallel threads. The record-locking database can permit different test cases of the plurality of test cases, executing via different parallel threads of plurality of parallel threads, to simultaneously access different records in the record-locking database.
“According to a third aspect, one or more non-transitory computer-readable media can store computer-executable instructions that, when executed by one or more processors, cause the one or more processors to perform operations. The operations can include instantiating a record-locking database associated with a software application, identifying a plurality of test cases associated with the software application, and distributing individual test cases of the plurality of test cases among a plurality of test sets. Different test sets of the plurality of test sets can be configured to execute simultaneously in different parallel threads. The operations can further include locking a first record in the record-locking database based on an access attempt by a first test case executing via a first parallel thread. The operations can also include granting a second test case access to a second record in the record-locking database while the first record is locked, wherein the second test case executes, via a second parallel thread, substantially simultaneously with the first test case executing via the first parallel thread.”
The claims supplied by the inventors are:
“1. A computer-implemented method, comprising: instantiating, by one or more processors of a computing device, a record-locking database associated with a software application; identifying, by the one or more processors, a plurality of test cases associated with the software application; distributing, by the one or more processors, individual test cases of the plurality of test cases among a plurality of test sets, wherein different test sets of the plurality of test sets are configured to execute simultaneously in different parallel threads on the computing device; locking, by the one or more processors, a first record in the record-locking database based on an access attempt by a first test case executing via a first parallel thread; and granting, by the one or more processors, a second test case access to a second record in the record-locking database while the first record is locked, wherein the second test case executes, via a second parallel thread, substantially simultaneously with the first test case executing via the first parallel thread.
“2. The computer-implemented method of claim 1, wherein: the plurality of test cases comprises a set of classes, individual classes, of the set of classes, comprise one or more methods, and the one or more methods are functions written in a programming language.
“3. The computer-implemented method of claim 2, wherein the distributing is performed at a class level.
“4. The computer-implemented method of claim 2, wherein the distributing is performed at a method level.
“5. The computer-implemented method of claim 1, further comprising: detecting, by the one or more processors, an attempt by a third test case to access the first record while the first record is locked, wherein the third test case executes, via a third parallel thread, substantially simultaneously with the first test case executing via the first parallel thread; determining, by the one or more processors, that the first record is unlocked following the access attempt by the first test case; and retrying, by the one or more processors, execution of the third test case based on determining that the first record is unlocked.
“6. The computer-implemented method of claim 1, wherein the record-locking database is an in-memory database.
“7. The computer-implemented method of claim 1, further comprising: generating, by the one or more processors, a local build of the software application based on code changes submitted locally, wherein the instantiating, the identifying, the distributing, the locking, and the granting are performed as part of a test process for the local build.
“8. The computer-implemented method of claim 1, further comprising: generating, by the one or more processors, a merge build of the software application based on code changes submitted locally and based on a master code branch associated with the software application, wherein the instantiating, the identifying, the distributing, the locking, and the granting are performed as part of a test process for the merge build.
“9. The computer-implemented method of claim 1, further comprising: collecting, by the one or more processors, a plurality of test results associated with the plurality of test sets configured to execute simultaneously in the different parallel threads; and generating, by the one or more processors, an aggregated test result report by combining the plurality of test results.
“10. A computing device, comprising: one or more processors; memory storing computer-executable instructions that, when executed by the one or more processors, cause the one or more processors to perform operations comprising: instantiating a record-locking database associated with a software application; identifying a plurality of test cases associated with the software application; distributing individual test cases of the plurality of test cases among a plurality of test sets, wherein the plurality of test sets corresponds to a plurality of parallel threads; and simultaneously executing the plurality of test sets via the plurality of parallel threads, wherein the record-locking database permits different test cases of the plurality of test cases, executing via different parallel threads of the plurality of parallel threads, to simultaneously access different records in the record-locking database.
“11. The computing device of claim 10, wherein the plurality of test cases comprises a set of classes, and individual classes of the set of classes comprise one or more methods.
“12. The computing device of claim 11, wherein the distributing is performed at a class level.
“13. The computing device of claim 11, wherein the distributing is performed at a method level.
“14. The computing device of claim 10, wherein the record-locking database is an in-memory database.
“15. One or more non-transitory computer-readable media storing computer-executable instructions that, when executed by one or more processors, cause the one or more processors to perform operations, comprising: instantiating a record-locking database associated with a software application; identifying a plurality of test cases associated with the software application; distributing individual test cases of the plurality of test cases among a plurality of test sets, wherein different test sets of the plurality of test sets are configured to execute simultaneously in different parallel threads; locking a first record in the record-locking database based on an access attempt by a first test case executing via a first parallel thread; and granting a second test case access to a second record in the record-locking database while the first record is locked, wherein the second test case executes, via a second parallel thread, substantially simultaneously with the first test case executing via the first parallel thread.
“16. The one or more non-transitory computer-readable media of claim 15, wherein: the plurality of test cases comprises a set of classes, individual classes of the set of classes comprise one or more methods, and the distributing is performed at one or more of a class level or a method level.
“17. The one or more non-transitory computer-readable media of claim 15, wherein the operations further comprise: detecting an attempt by a third test case to access the first record while the first record is locked, wherein the third test case executes, via a third parallel thread, substantially simultaneously with the first test case executing via the first parallel thread; determining that the first record is unlocked following the access attempt by the first test case; and retrying execution of the third test case based on determining that the first record is unlocked.
“18. The one or more non-transitory computer-readable media of claim 15, wherein the record-locking database is an in-memory database.
“19. The one or more non-transitory computer-readable media of claim 15, wherein the operations further comprise: generating a new build of the software application based at least in part on code changes, wherein the instantiating, the identifying, the distributing, the locking, and the granting are performed as part of a test process for the new build.
“20. The one or more non-transitory computer-readable media of claim 15, wherein the operations further comprise: collecting a plurality of test results associated with the plurality of test sets configured to execute simultaneously in the different parallel threads; and generating an aggregated test result report by combining the plurality of test results.”
For additional information on this patent, see: Chauhan, Shaktiraj. Software testing in parallel threads with a record-locking database.
(Our reports deliver fact-based news of research and discoveries from around the world.)
Patent Issued for Data processing system with machine learning engine to provide output generating functions (USPTO 11537935): Allstate Insurance Company
Studies from Georgia Institute of Technology in the Area of Insurance Described (Impacts of Publicly Funded Health Insurance for Adults On Children’s Academic Achievement): Insurance
Advisor News
Annuity News
Health/Employee Benefits News
Life Insurance News