Abstract: This disclosure describes techniques for performing batch processing using a custom batch processing routine (e.g., a custom filtering routine) that calls a native batch processing routine (e.g., a native filtering routine) associated with a batch processing system as well as a rule database for one or more additional filtering rules. In some cases, a custom filtering routine may be configured to: (i) receive a batch of data, (ii) call a native filtering routine to process the received batch data, and (iii) apply one or more additional filtering operations on the output of the native filtering routine. For example, the custom filtering routine may be configured to: (i) make a query to the rule database to extract one or more filtering rules, and (ii) apply the extracted filtering rules to the output of the native filtering routine to perform the additional filtering operations.

Abstract: Annotations associated with test cases written to test a software application can allow related test cases to be dynamically distributed among different sets of test cases that can be executed simultaneously in different parallel threads, thereby speeding up testing relative to executing the test cases sequentially in a single thread. The annotations can also allow test cases to be identified that are relevant to code changes, such that testing times can be further reduced by executing a subset of test cases relevant to code changes instead of a full set of test cases.

Abstract: A software project management system can store object data about components of a software development project, such epics, features, and stories. The software project management system can also store dependency objects that reflect dependency relationships between two or more components of the software development project. The dependency objects can track status information about the dependency relationships, including expected completion dates, acceptance criteria, and state indicators. The information stored in the dependency objects can be updated over time as information about the dependency relationship changes. The software project management system can also use the dependency objects to display information in a user interface about one or more dependency relationships, such as to indicate which dependency relationships are on track or behind schedule.

Abstract: Test cases written to test a software application can be dynamically distributed among different sets of test cases that can be executed simultaneously in different parallel threads, thereby speeding up testing relative to executing the test cases sequentially in a single thread. Although executing the test cases in parallel threads can cause the test cases to execute in a different order than intended by developers, any test cases that fail due to database conflicts or other errors as a result of the parallelization can be retried at least once. Re-executing failed test cases at a later time can lead to the full set of test cases ultimately succeeding, despite errors that may have been caused by the parallelization.

Abstract: Annotations associated with test cases written to test a software application can allow related test cases to be dynamically distributed among different sets of test cases that can be executed simultaneously in different parallel threads, thereby speeding up testing relative to executing the test cases sequentially in a single thread. The annotations can also allow test cases to be identified that are relevant to code changes, such that testing times can be further reduced by executing a subset of test cases relevant to code changes instead of a full set of test cases.

Abstract: Mutation testing can indicate whether mutants of a software application, created by intentionally altering source code of the software application, are successfully “killed” by test cases executed against the mutants. Mutation testing can be performed via parallel threads by, within each parallel thread, modifying individual source code class files and recompiling the modified class files to generate and test mutants. Individual mutation test results produced within each of the parallel threads can be aggregated to generate an aggregated test result report that indicates overall testing metrics associated with the mutation testing across the parallel threads.

Abstract: This disclosure describes techniques for performing batch processing using a custom batch processing routine (e.g., a custom filtering routine) that calls a native batch processing routine (e.g., a native filtering routine) associated with a batch processing system as well as a rule database for one or more additional filtering rules. In some cases, a custom filtering routine may be configured to: (i) receive a batch of data, (ii) call a native filtering routine to process the received batch data, and (iii) apply one or more additional filtering operations on the output of the native filtering routine. For example, the custom filtering routine may be configured to: (i) make a query to the rule database to extract one or more filtering rules, and (ii) apply the extracted filtering rules to the output of the native filtering routine to perform the additional filtering operations.

Abstract: Mutation testing can indicate whether mutants of a software application, created by intentionally altering source code of the software application, are successfully “killed” by test cases executed against the mutants. Mutation testing can be performed via parallel threads by, within each parallel thread, modifying individual source code class files and recompiling the modified class files to generate and test mutants. Individual mutation test results produced within each of the parallel threads can be aggregated to generate an aggregated test result report that indicates overall testing metrics associated with the mutation testing across the parallel threads.

Abstract: Techniques described herein relate to implementing mutation testing of software applications associated with continuous integration (CI) systems. A mutation test system may determine one or more portions of modified source code within an application codebase. Mutated applications may be generated based on the modified source code, and a mutation test system may determine subsets application test suites for execution based on the portions of the modified source code and/or other factors. In various examples, the mutation test system may use mappings between portions of source code and test subsets, and/or machine-learned models or heuristics-based techniques to determine subsets of test suites based on discreet source code modifications.

Abstract: Techniques described herein relate to implementing mutation testing of software applications associated with continuous integration (CI) systems. A mutation test system may determine one or more portions of modified source code within an application codebase. Mutated applications may be generated based on the modified source code, and a mutation test system may determine subsets application test suites for execution based on the portions of the modified source code and/or other factors. In various examples, the mutation test system may use mappings between portions of source code and test subsets, and/or machine-learned models or heuristics-based techniques to determine subsets of test suites based on discreet source code modifications.

Abstract: A software project management system can store object data about components of a software development project, such epics, features, and stories. The software project management system can also store dependency objects that reflect dependency relationships between two or more components of the software development project. The dependency objects can track status information about the dependency relationships, including expected completion dates, acceptance criteria, and state indicators. The information stored in the dependency objects can be updated over time as information about the dependency relationship changes. The software project management system can also use the dependency objects to display information in a user interface about one or more dependency relationships, such as to indicate which dependency relationships are on track or behind schedule.

Abstract: A software project management system can store object data about components of a software development project, such epics, features, and stories. The software project management system can also store dependency objects that reflect dependency relationships between two or more components of the software development project. The dependency objects can track status information about the dependency relationships, including expected completion dates, acceptance criteria, and state indicators. The information stored in the dependency objects can be updated over time as information about the dependency relationship changes. The software project management system can also use the dependency objects to display information in a user interface about one or more dependency relationships, such as to indicate which dependency relationships are on track or behind schedule.

Abstract: In association with unit and integration testing of a software application, a test conflict guard can detect whether test cases are independent and use distinct database data, or are related or dependent test cases that use the same database data. The test conflict guard can detect any related or dependent test cases in a group of test cases, which may cause testing errors if executed in different parallel threads. The test conflict guard can accordingly block test execution until the group of test cases are verified as independent test cases.

Abstract: A software project management system can store object data about components of a software development project, such epics, features, and stories. The software project management system can also store dependency objects that reflect dependency relationships between two or more components of the software development project. The dependency objects can track status information about the dependency relationships, including expected completion dates, acceptance criteria, and state indicators. The information stored in the dependency objects can be updated over time as information about the dependency relationship changes. The software project management system can also use the dependency objects to display information in a user interface about one or more dependency relationships, such as to indicate which dependency relationships are on track or behind schedule.

Abstract: Test cases written to test a software application can be dynamically distributed among different sets of test cases that can be executed simultaneously in different parallel threads, thereby speeding up testing relative to executing the test cases sequentially in a single thread. 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 locking entire database tables or locking data structures that are larger than individual records. Locking individual database records 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.

Abstract: Mutation testing can indicate whether mutants of a software application, created by intentionally altering source code of the software application, are successfully “killed” by test cases executed against the mutants. Mutation testing can be performed via parallel threads by, within each parallel thread, modifying individual source code class files and recompiling the modified class files to generate and test mutants. Individual mutation test results produced within each of the parallel threads can be aggregated to generate an aggregated test result report that indicates overall testing metrics associated with the mutation testing across the parallel threads.

Abstract: In association with unit and integration testing of a software application, a test conflict guard can detect whether test cases are independent and use distinct database data, or are related or dependent test cases that use the same database data. The test conflict guard can detect any related or dependent test cases in a group of test cases, which may cause testing errors if executed in different parallel threads. The test conflict guard can accordingly block test execution until the group of test cases are verified as independent test cases.

Abstract: Mutation testing can indicate whether mutants of a software application, created by intentionally altering source code of the software application, are successfully “killed” by test cases executed against the mutants. Mutation testing can be performed via parallel threads by, within each parallel thread, modifying individual source code class files and recompiling the modified class files to generate and test mutants. Individual mutation test results produced within each of the parallel threads can be aggregated to generate an aggregated test result report that indicates overall testing metrics associated with the mutation testing across the parallel threads.

Abstract: Test cases written to test a software application can be dynamically distributed among a set of software application instances such that different sets of test cases can execute simultaneously in parallel, thereby speeding up testing relative to executing the test cases sequentially. To avoid database conflicts that may occur when different test cases are executed in parallel, each software application instance can be associated with a different database instance. Accordingly, a first test case executing in association with a first database instance can avoid interfering with a second test case executing in association with a second database instance.

Abstract: In mutation testing, source code is mutated at various positions, and test suites are run against the original object code and each version of the mutated object code, to determine the quality of test suites against arbitrary changes in the object code. The present disclosure provides a mutation test manager configured to initialize multiple computing threads configuring a computing host to perform parallel computation; mutate class files within context of each computing thread; recompile mutated class files independently in each respective computing thread to generate heterogeneous mutants; and execute pending unit tests against heterogeneous mutants independently in each respective computing thread. Consequently, the mutation testing process is decoupled from computational bottlenecks which would result from linear, sequential generation, compilation, and testing of each mutation, especially in the context of JVM® programming languages configured to generate class-rich object code.