Skip to content

repairnator/repairnator-experiments-one-failing-test-case

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 

Repository files navigation

Code-removal Patches associated with Travis CI builds having only one failing test case

This is an open-science repository that collects the Code-removal patches generated by Repairnator during the analysis of the Travis CI builds characterised by only one failing test case and no crashing test cases.

This repository aims to contain the code of the failing Java projects and to analyze the code-removal patches generated using AstorJKali.

Content of the repository

The structure of the repository is as follows:

  • Branch master contains the jkali-patches folder and the documentation of this repository;
  • The jkali-patches folder contains the patches generated by Repairnator (using the AstorJKali repair mode) analyzing the Travis CI build failure related to Java programs that use Maven as building tool;
  • For each of these failing builds, there is a specific branch with all the information related to the building of the project, bug reproduction, failing tests and repair attempts.

Statistics

The builds collected in the dataset repairnator-experiments with only one failing test case are 2.381. In the following table, there are the different states of the builds detected by Repairnator during the analysis:

Failing Patched Not clonable Not buildable Not checked out Not testable Not failing
Number of the builds 950 27 - 275 - 50 262

In this repository there are 950 branches (excluding master branch), each of them associated with a failure.

Patch Analysis

EnMasseProject-enmasse-353457987-20180314-185443

Failure type Failing test case Changed file by AstorJKali
org.mockito.exceptions.verification.TooLittleActualInvocations FifoQueueTest.java FifoQueue.java
  • Kali patch:
--- /src/main/java/io/enmasse/k8s/api/cache/FifoQueue.java
+++ /src/main/java/io/enmasse/k8s/api/cache/FifoQueue.java
@@ -44,7 +44,6 @@
 			return;
 		}
 		java.util.List<io.enmasse.k8s.api.cache.FifoQueue.Event<T>> events = new java.util.ArrayList<>();
-		queue.drainTo(events);
 		java.lang.String key = null;
 		if (event.obj != null) {
 			key = keyExtractor.getKey(event.obj);
  • Overview: the problem is related to the test case that checks the correct behavior of the method changed by AstorJKali. Indeed, looking at the commit history of the project, the developer changed the test case to handle the failure associated with the use of method draintTo, that is the method removed by AstorJKali to create the patch.

  • Reason why the patch has been generated: AstorJKali managed to generate a patch because the test case only checks if the FifoQueue object is empty or not, but it doesn't check the inner properties of that object. In particular, it doesn't check the size of the private member variable queue. Thus, removing the call to the method drainTo in the method pop (as AstorJKali did), the queue queue is not really emptied, and so the method pop is executed two times (even if the queue should have been emptied the first time) satisfying the test case that checks how many times that method is called.

  • Useful information for the developer: the Kali patch suggested that there was a problem with the method drainTo or with the test case testRemove that checks the behavior of that method. In this case, since the method drainTo is a method of the JDK, there is more probability that the error is not related to that method, but in the way used to test it. Thus, the developer can start to analyze the problem focusing on the test case, checking if it is correct or not.

  • Fix of the test case:

From 848ff42b0ed3fa5888778957ac8daca909c98072 Mon Sep 17 00:00:00 2001
From: Ulf Lilleengen <lulf@redhat.com>
Date: Wed, 14 Mar 2018 20:29:54 +0100
Subject: Fix test to handle drain

---
 .../src/test/java/io/enmasse/k8s/api/cache/FifoQueueTest.java   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/k8s-api/src/test/java/io/enmasse/k8s/api/cache/FifoQueueTest.java b/k8s-api/src/test/java/io/enmasse/k8s/api/cache/FifoQueueTest.java
index 213c76fef1..ec7b7fda7f 100644
--- a/k8s-api/src/test/java/io/enmasse/k8s/api/cache/FifoQueueTest.java
+++ b/k8s-api/src/test/java/io/enmasse/k8s/api/cache/FifoQueueTest.java
@@ -61,7 +61,7 @@ public void testRemove() throws Exception {
         assertTrue(queue.list().isEmpty());
 
         queue.pop(mockProc, 0, TimeUnit.SECONDS);
-        verify(mockProc, times(2)).process(eq("k1"));
+        verify(mockProc).process(eq("k1"));
         assertTrue(queue.listKeys().isEmpty());
         assertTrue(queue.list().isEmpty());
     }

Inmapg-Text-Traffic-Simulator-368867994-20180419-235104

Failure type Failing test case Changed file by AstorJKali
java.lang.AssertionError VehicleTest.java IniSection.java
  • Kali patch:
--- /src/main/java/pr5/ini/IniSection.java
+++ /src/main/java/pr5/ini/IniSection.java
@@ -85,7 +85,6 @@
 		}
 		for (java.lang.String key : this.getKeys()) {
 			if (!this.getValue(key).equals(other.getValue(key))) {
-				return false;
 			}
 		}
 		return true;
  • Overview: the problem is related to the test case that checks the correct behavior of the method changed by AstorJKali. Indeed, looking at the commit history of the project, the developer changed the test case to handle the failure during the comparison of two Vehicle objects.

  • Reason why the patch has been generated: AstorJKali managed to create a patch because the test case expects that two IniSection objects are equals, and since the patch removes the return false instruction, the objects are always equal, even if they are different. For this reason, there isn't the possibilty to recognise the error in the current test case. It is necessary to add some other checks in the test case that require false as expected value (e.g., a check of the individual properties of the objects, after a change to one of them, without the use of method equals).

  • Useful information for the developer: the Kali patch suggested that there was a problem with the method equals or with the test case VehicleFaultyTest that checks the behavior of that method. Since it's correct that when two values are different the result of the comparison is false (this instruction has been removed by AstorJKali to create the fix), the developer can focus on the implementation of the test case to try to understand where the error might be.

  • Fix of the test case:

From e59608185c3f326d46eb82371614d5ee354a9ba9 Mon Sep 17 00:00:00 2001
From: Inma <Inma@eduroam162180.eduroam.ucm.es>
Date: Thu, 19 Apr 2018 23:54:13 +0200
Subject: [PATCH] Fixing VehicleTest class

---
 src/test/java/pr5/tmodel/VehicleTest.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/test/java/pr5/tmodel/VehicleTest.java b/src/test/java/pr5/tmodel/VehicleTest.java
index 2248632..ca127a5 100755
--- a/src/test/java/pr5/tmodel/VehicleTest.java
+++ b/src/test/java/pr5/tmodel/VehicleTest.java
@@ -109,7 +109,7 @@ public void VehicleFaultyTest(){
         assertEquals(correct, result);
         vehicle.makeFaulty(2);
         correct.setValue("time", "2");
-        correct.setValue("speed", "10");
+        correct.setValue("speed", "0");
         correct.setValue("faulty", "2");
         result = vehicle.generateReport(2);
         assertEquals(correct, result);

KGreg314-ivt-lab-380634197-20180518-125533

Failure type Failing test case Changed file by AstorJKali
java.lang.AssertionError GT4500Test.java GT4500.java
  • Kali patch:
--- /src/main/java/hu/bme/mit/spaceship/GT4500.java
+++ /src/main/java/hu/bme/mit/spaceship/GT4500.java
@@ -20,25 +20,25 @@
 @java.lang.Override
 public boolean fireTorpedo(hu.bme.mit.spaceship.FiringMode firingMode) {
  boolean firingSuccess = false;
- if (firingMode == hu.bme.mit.spaceship.FiringMode.SINGLE) {
     if (wasPrimaryFiredLast) {
      if (!secondaryTorpedoStore.isEmpty()) {
       firingSuccess = secondaryTorpedoStore.fire(1);
       wasPrimaryFiredLast = false;
+ if (true) {
     if (wasPrimaryFiredLast) {
      if (!secondaryTorpedoStore.isEmpty()) {
       firingSuccess = this.secondaryTorpedoStore.fire(1);
       this.wasPrimaryFiredLast = false;
  • Overview: the problem is related to the outermost else branch of the method removed by AstorJKali. Indeed, looking at the commit history of the project, the developer implemented the outermost else branch in the next commit.
  • Reason why the patch has been generated: the test cases don't cover all of the possible paths of the method fireTorpedo, that is the bugged method changed by AstorJKali. In particular, applying the Kali patch, the method fireTorpedo executed by the failing test case returns the default value (false) that is the value expected by the test to pass. Actually, the test cases passes just because the default value is the same of the exptected value by the test case, and not because of the correctness of the patch.
  • Useful information for the developer: the Kali patch suggested that the feature associated with the else branch (removed by the patch generated by AstorJKali) had an error. Indeed, looking at the source code, the else branchhad yet to be implemented by the developer.
  • Fix of the source code:
From 5669e29937d3a18c4ac17d5e33ba2dd03cd5ec75 Mon Sep 17 00:00:00 2001
From: meres <kgreg314@gmail.com>
Date: Fri, 18 May 2018 04:05:40 -0700
Subject: [PATCH] Add JoCoCo & Implement ALL firing mode perfectly

diff --git a/src/main/java/hu/bme/mit/spaceship/GT4500.java b/src/main/java/hu/bme/mit/spaceship/GT4500.java
index 48160c0..bbcd26d 100644
--- a/src/main/java/hu/bme/mit/spaceship/GT4500.java
+++ b/src/main/java/hu/bme/mit/spaceship/GT4500.java
@@ -78,7 +78,18 @@ public boolean fireTorpedo(FiringMode firingMode) {
      else{
         // try to fire both of the torpedo stores
         //TODO implement feature
-	firingSuccess = true;
+        if (! primaryTorpedoStore.isEmpty() && ! secondaryTorpedoStore.isEmpty()) {
+          boolean successPrimary = primaryTorpedoStore.fire(1);
+	        boolean successSecondary = secondaryTorpedoStore.fire(1);
+	        firingSuccess = successPrimary || successSecondary;
+          wasPrimaryFiredLast = false;
+        } else if (! primaryTorpedoStore.isEmpty()) {
+            firingSuccess = primaryTorpedoStore.fire(1);
+            wasPrimaryFiredLast = true;          
+        } else if (! secondaryTorpedoStore.isEmpty()) {
+            firingSuccess = secondaryTorpedoStore.fire(1);
+            wasPrimaryFiredLast = false;          
+        }
 
         
     }

apache-commons-rng-354875355-20180318-011906

Failure type Failing test case Changed file by AstorJKali
java.lang.AssertionError ContinuousSamplerParametricTest.java RejectionInversionZipfSampler.java
  • Kali patch:
--- /src/main/java/org/apache/commons/rng/sampling/distribution/RejectionInversionZipfSampler.java
+++ /src/main/java/org/apache/commons/rng/sampling/distribution/RejectionInversionZipfSampler.java
@@ -22,9 +22,6 @@
 
 	public RejectionInversionZipfSampler(org.apache.commons.rng.UniformRandomProvider rng, int numberOfElements, double exponent) {
 		super(rng);
-		if (numberOfElements <= 0) {
-			throw new java.lang.IllegalArgumentException("number of elements is not strictly positive: " + numberOfElements);
-		}
 		if (exponent <= 0) {
 			throw new java.lang.IllegalArgumentException("exponent is not strictly positive: " + exponent);
 		}
  • Overview: It's a flaky test case. The test case fails when the method check() of class ContinuousSamplerParametricTest enters in this if branch. The condition is satisfied when the ratio between the number of failures and the number of tests is greater then a certain threshold (0.05).
  • Reason why the patch has been generated: Since the Kali patch removes the instruction that throws an exception, even though a test case should terminate with a failure, actually it doesn't occur, and so the number of failing test cases doesn't increment.

The test case fails only when a certain condition is satisifed. Since the Kali patch avoids the increase of the number of exceptions thrown, the test case doesn't fail anymore.

  • Useful information for the developer: It's a flaki test, so if the developer finds out that the implementation is correct both with and without the Kali patch, she can try to understand how to change the test case, or remove it.

apache-commons-rng-403087258-20180712-141947

Failure type Failing test case Changed file by AstorJKali
java.lang.AssertionError ContinuousSamplerParametricTest.java RejectionInversionZipfSampler.java
  • Kali patch:
--- /src/main/java/org/apache/commons/rng/sampling/distribution/RejectionInversionZipfSampler.java
+++ /src/main/java/org/apache/commons/rng/sampling/distribution/RejectionInversionZipfSampler.java
@@ -22,9 +22,6 @@
 
 	public RejectionInversionZipfSampler(org.apache.commons.rng.UniformRandomProvider rng, int numberOfElements, double exponent) {
 		super(rng);
-		if (numberOfElements <= 0) {
-			throw new java.lang.IllegalArgumentException("number of elements is not strictly positive: " + numberOfElements);
-		}
 		if (exponent <= 0) {
 			throw new java.lang.IllegalArgumentException("exponent is not strictly positive: " + exponent);
 		}
  • Overview: Equal to the build apache-commons-rng-354875355-20180318-011906

atomix-atomix-365170225-20180411-171152

The build was failing also before this one.

  • Information about the failure:
Failure type Failing test case Changed file by AstorJKali
java.lang.AssertionError DefaultClusterServiceTest.java DefaultClusterService.java
  • Kali patch:
--- /src/main/java/io/atomix/cluster/impl/DefaultClusterService.java
+++ /src/main/java/io/atomix/cluster/impl/DefaultClusterService.java
@@ -91,7 +91,7 @@
 			io.atomix.cluster.impl.PhiAccrualFailureDetector failureDetector = failureDetectors.computeIfAbsent(node.id(), ( n) -> new io.atomix.cluster.impl.PhiAccrualFailureDetector());
 			double phi = failureDetector.phi();
 			if ((phi > 0) && ((phi >= phiFailureThreshold) || ((java.lang.System.currentTimeMillis() - failureDetector.lastUpdated()) > io.atomix.cluster.impl.DefaultClusterService.DEFAULT_FAILURE_TIME))) {
-				if (node.getState() == io.atomix.cluster.Node.State.ACTIVE) {
+				if (true) {
 					deactivateNode(node);
 				}
 			} else {
  • Overview: The error is related to the status check of a Node.

  • Reason why the patch has been generated: AstorJKali managed to create a patch, because changing the if condition, it forced the execution of method deactivateNode. This method uses another way to get the node object (it uses the node id, and it gets the node based on this id, checking in a Map), so that when its status is checked, it is ACTIVE (and not INACTIVE), and thus the method deactivate(Node) is executed full. In this way, the node is deactivated and the assertion is satisfied.

  • Useful information for the developer: The developer can see how the status of Node is got in the method deactivateNode, and use the same way to check the status in the if condition changed by AstorJKali. Indeed, in this way, all the test cases pass.

  • Possible fix:

- if (node.getState() == State.ACTIVE) {
+ if (this.nodes.get(node.id()).getState() == State.ACTIVE)

Pull Request History: atomix/atomix#484

BradleyWood-Software-Quality-Test-Framework-351075282-20180309-001538

Failure type Failing test case Changed file by AstorJKali
java.lang.AssertionError TestClassTest.java TestClass.java
  • Kali patch:
--- /src/main/java/org/sqtf/TestClass.java
+++ /src/main/java/org/sqtf/TestClass.java
@@ -133,27 +133,6 @@
 				continue;
 			}
 			int timeout = m.timeout();
-			if (params != null) {
-				java.util.List<java.lang.Object[]> testParameterList = getTestParameters(params.csvfile(), testMethod.getParameterTypes());
-				if (testParameterList != null) {
-					for (java.lang.Object[] objects : testParameterList) {
-						org.sqtf.TestResult result = runTest(testMethod, instance, timeout, objects);
-						resultCache.add(result);
-						final org.sqtf.TestResult finalResult = result;
-						listeners.forEach(( l) -> l.testCompleted(clazz.getSimpleName(), testMethod.getName(), finalResult.passed()));
-					}
-				} else {
-					org.sqtf.TestResult result = new org.sqtf.TestResult(testMethod, new org.sqtf.InvalidTestException(""), 0);
-					resultCache.add(result);
-					final org.sqtf.TestResult finalResult = result;
-					listeners.forEach(( l) -> l.testCompleted(clazz.getSimpleName(), testMethod.getName(), finalResult.passed()));
-				}
-			} else {
-				org.sqtf.TestResult result = runTest(testMethod, instance, timeout);
-				resultCache.add(result);
-				final org.sqtf.TestResult finalResult = result;
-				listeners.forEach(( l) -> l.testCompleted(clazz.getSimpleName(), testMethod.getName(), finalResult.passed()));
-			}
 		}
 		listeners.forEach(( l) -> l.classCompleted(clazz.getSimpleName(), testClassPassed.get()));
 		finishTime = java.lang.System.currentTimeMillis();
  • Overview: The problem is related to a failing test case that should have passed. The failure reason is the absence of the data required by the failing test case. Indeed, looking at the commit history of the project, the next commit after the failure adds the test data, and the test case no longer fails.

  • Reason why the patch has been generated: AstorJKali managed to create a patch because the failing assert is executed only if certain conditions are satisfied. Removing the piece of code associated with the patch generated by AstorJKali, this assert is no longer executed, and so the the program passes all the test cases.

  • Useful information for the developer: AstorJKali removed a piece of code whose first line contains the use of method csvfile() to get the paths of files necessary for the test cases. If she checks the paths, she can uderstand that the files are missing, and so she can fix the failure.

  • Travis CI Fixed Build information: https://api.travis-ci.org/v3/build/351075788

  • Human fix: https://github.com/BradleyWood/Software-Quality-Test-Framework/compare/1392f1bfd1ba...757bfbfffc78

cqse-test-analyzer-397786068-20180628-145935

Failure type Failing test case Changed file by AstorJKali
org.junit.ComparisonFailure SurefireTestListenerTest.java AbstractSurefireTestListener.java
  • Kali patch:
--- /src/main/java/de/tum/in/niedermr/ta/extensions/analysis/workflows/stackdistance/maven/AbstractSurefireTestListener.java
+++ /src/main/java/de/tum/in/niedermr/ta/extensions/analysis/workflows/stackdistance/maven/AbstractSurefireTestListener.java
@@ -80,10 +80,9 @@
 
 	@java.lang.Override
 	public synchronized void testFinished(org.junit.runner.Description description) throws java.lang.Exception {
-		if (m_currentTestcaseFailed) {
-			writeCommentToResultFile("Failing test case: " + createTestcaseIdentifier(description).get());
+		if (m_currentTestcaseFailed)
 			return;
-		}
+
 		appendStackDistanceOfTestcaseToResult(createTestcaseIdentifier(description));
 	}
  • Overview: The problem is related to the comparison between the value returned by a test case and a .txt file with the expected output.

  • Reason why the patch has been generated: AstorJKali managed to create the patch because it removed the instruction that adds the line missing in the expected output. In this way, the content of file and the expected output are equal. Adding a new test case that checks if the output contains a line with an exception, it would avoid the generation of the Kali patch.

  • Useful information for the developer:

  • Travis CI Fixed Build information: https://api.travis-ci.org/v3/build/397848105

  • Human fix: https://github.com/cqse/test-analyzer/compare/901b08fede34...c3fee55007d9

diff --git a/test-analyzer-sdist/src/main/java/de/tum/in/niedermr/ta/extensions/analysis/workflows/stackdistance/maven/SurefireSqlTestListener.java b/test-analyzer-sdist/src/main/java/de/tum/in/niedermr/ta/extensions/analysis/workflows/stackdistance/maven/SurefireSqlTestListener.java
index d3022047..ef086412 100644
--- a/test-analyzer-sdist/src/main/java/de/tum/in/niedermr/ta/extensions/analysis/workflows/stackdistance/maven/SurefireSqlTestListener.java
+++ b/test-analyzer-sdist/src/main/java/de/tum/in/niedermr/ta/extensions/analysis/workflows/stackdistance/maven/SurefireSqlTestListener.java
@@ -27,7 +27,7 @@ protected String getDefaultOutputFileExtension() {
 	/** {@inheritDoc} */
 	@Override
 	protected void writeCommentToResultFile(IResultReceiver resultReceiver, String comment) {
-		resultReceiver.append("#" + comment);
+		resultReceiver.append("# " + comment);
 	}
 
 	/** {@inheritDoc} */
diff --git a/test-analyzer-sdist/src/test/data/SurefireTestListenerTest/expected-output.txt b/test-analyzer-sdist/src/test/data/SurefireTestListenerTest/expected-output.txt
index 6d3a65bd..2536406b 100644
--- a/test-analyzer-sdist/src/test/data/SurefireTestListenerTest/expected-output.txt
+++ b/test-analyzer-sdist/src/test/data/SurefireTestListenerTest/expected-output.txt
@@ -1,5 +1,6 @@
-#INFO Stack distance setup successful.
+# INFO Stack distance setup successful.
 INSERT INTO Stack_Info_Import (execution, testcase, method, minStackDistance, invocationCount) VALUES ('????', 'de.tum.in.niedermr.ta.sample.junit.SampleJUnitTestClass;testCase1', 'de.tum.in.niedermr.ta.sample.SampleClass.c(java.lang.String)', '4', '2'); 
 INSERT INTO Stack_Info_Import (execution, testcase, method, minStackDistance, invocationCount) VALUES ('????', 'de.tum.in.niedermr.ta.sample.junit.SampleJUnitTestClass;testCase1', 'de.tum.in.niedermr.ta.sample.SampleClass.b(boolean)', '3', '1'); 
 INSERT INTO Stack_Info_Import (execution, testcase, method, minStackDistance, invocationCount) VALUES ('????', 'de.tum.in.niedermr.ta.sample.junit.SampleJUnitTestClass;testCase1', 'de.tum.in.niedermr.ta.sample.SampleClass.a(int,int)', '2', '1'); 
 INSERT INTO Stack_Info_Import (execution, testcase, method, minStackDistance, invocationCount) VALUES ('????', 'de.tum.in.niedermr.ta.sample.junit.SampleJUnitTestClass;testCase1', 'de.tum.in.niedermr.ta.sample.SampleClass.a()', '1', '2'); 
+# Failing test case: de.tum.in.niedermr.ta.sample.junit.SampleJUnitTestClass;testCase2
\ No newline at end of file

dotwebstack-dotwebstack-framework-363986485-20180409-090844

Failure type Failing test case Changed file by AstorJKali
java.lang.AssertionError DirectEndPointRequestMapperTest.java DirectEndPointRequestMapper.java
  • Kali patch:
--- /src/main/java/org/dotwebstack/framework/frontend/ld/mappers/DirectEndPointRequestMapper.java
+++ /src/main/java/org/dotwebstack/framework/frontend/ld/mappers/DirectEndPointRequestMapper.java
@@ -44,7 +44,6 @@
 		java.lang.String basePath = endPoint.getStage().getFullPath();
 		java.lang.String absolutePath = basePath.concat(endPoint.getPathPattern());
 		final java.util.Optional<org.dotwebstack.framework.frontend.ld.service.Service> deleteService = java.util.Optional.ofNullable(endPoint.getDeleteService());
-		deleteService.ifPresent(( service) -> registerTransaction(service, javax.ws.rs.HttpMethod.DELETE, absolutePath, httpConfiguration));
 		final java.util.Optional<org.dotwebstack.framework.frontend.ld.service.Service> postService = java.util.Optional.ofNullable(endPoint.getPostService());
 		postService.ifPresent(( service) -> registerTransaction(service, javax.ws.rs.HttpMethod.POST, absolutePath, httpConfiguration));
 		final java.util.Optional<org.dotwebstack.framework.frontend.ld.service.Service> putService = java.util.Optional.ofNullable(endPoint.getPutService());

dropwizard-metrics-374587117-20180503-220610-firstCommit

Failure type Failing test case Changed file by AstorJKali
org.mockito.exceptions.verification.WantedButNotInvoked InstrumentedHttpClientsTimerTest.java InstrumentedNHttpClientBuilder.java
  • Kali patch:
--- /src/main/java/io/dropwizard/metrics5/httpasyncclient/InstrumentedNHttpClientBuilder.java
+++ /src/main/java/io/dropwizard/metrics5/httpasyncclient/InstrumentedNHttpClientBuilder.java
@@ -85,8 +85,8 @@
 		@java.lang.Override
 		public void failed(java.lang.Exception ex) {
 			timerContext.stop();
-			if (callback != null) {
+			if (true) {
  • Overview: The failure is related to a flaky test case. Indeed, it can fails due to a timeout, but not for other reasons.
  • Reason why the patch has been generated: The Kali patch changed a piece of code that is not executed by the failing test case.
  • Useful information for the developer:

eclipse-hono-338971473-20180208-141728-firstCommit

Failure type Failing test case Changed file by AstorJKali
org.mockito.exceptions.verification.WantedButNotInvoked EventConsumerImplTest.java AbstractHonoClient.java
  • Kali patch:
--- /src/main/java/org/eclipse/hono/client/impl/AbstractHonoClient.java
+++ /src/main/java/org/eclipse/hono/client/impl/AbstractHonoClient.java
@@ -149,7 +149,7 @@
 					org.eclipse.hono.client.impl.AbstractHonoClient.LOG.debug("receiver open attach failed [{}] by peer [{}]: {}", receiver.getRemoteSource(), con.getRemoteContainer(), openAttach.cause().getMessage());
 					result.fail(openAttach.cause());
 				} else {
-					if (org.eclipse.hono.client.impl.AbstractHonoClient.LOG.isTraceEnabled()) {
+					if (true) {
 						org.eclipse.hono.client.impl.AbstractHonoClient.LOG.trace("receiver open attach succeeded [{}] by peer [{}]", receiver.getRemoteSource(), con.getRemoteContainer());
 					}
 					result.complete(openAttach.result());
  • Overview:
  • Reason why the patch has been generated:
  • Useful information for the developer:

EnMasseProject-enmasse-378592651-20180514-093752-firstCommit

Failure type Failing test case Changed file by AstorJKali
java.lang.AssertionError ArtemisTest.java Artemis.java
  • Kali patch:
--- /src/main/java/io/enmasse/amqp/Artemis.java
+++ /src/main/java/io/enmasse/amqp/Artemis.java
@@ -83,7 +83,7 @@
 		source.setDynamic(true);
 		receiver.setSource(source);
 		receiver.openHandler(( h) -> {
-			if (h.succeeded()) {
+			if (true) {
 				promise.complete(new io.enmasse.amqp.Artemis(vertx.getOrCreateContext(), connection, sender, receiver, h.result().getRemoteSource().getAddress(), replies));
 			} else {
 				if (retries > io.enmasse.amqp.Artemis.maxRetries) {
  • Overview:
  • Reason why the patch has been generated:
  • Useful information for the developer:

EnMasseProject-enmasse-387846982-20180604-173506-firstCommit

Failure type Failing test case Changed file by AstorJKali
java.lang.AssertionError HTTPServerTest.java APIGroupVersion.java
  • Kali patch:
--- /src/main/java/io/enmasse/api/v1/types/APIGroupVersion.java
+++ /src/main/java/io/enmasse/api/v1/types/APIGroupVersion.java
@@ -13,7 +13,6 @@
 
 	public APIGroupVersion(java.lang.String groupVersion, java.lang.String version) {
 		this.groupVersion = groupVersion;
-		this.version = version;
 	}
 
 	@com.fasterxml.jackson.annotation.JsonProperty("groupVersion")
  • Overview:
  • Reason why the patch has been generated:
  • Useful information for the developer:

INL-BlackLab-214962527-20170325-134416-firstCommit

Failure type Failing test case Changed file by AstorJKali
java.lang.AssertionError TestSearchesNfa.java BLSpanOrQuery.java
  • Kali patch:
--- /src/main/java/nl/inl/blacklab/search/lucene/BLSpanOrQuery.java
+++ /src/main/java/nl/inl/blacklab/search/lucene/BLSpanOrQuery.java
@@ -489,9 +489,9 @@
 	public boolean canMakeNfa() {
 		for (org.apache.lucene.search.spans.SpanQuery cl : getClauses()) {
 			nl.inl.blacklab.search.lucene.BLSpanQuery clause = ((nl.inl.blacklab.search.lucene.BLSpanQuery) (cl));
-			if (!clause.canMakeNfa())
+			if (true) {
 				return false;
-
+			}
 		}
 		return true;
 	}
  • Overview:
  • Reason why the patch has been generated:
  • Useful information for the developer:

jguyet-HttpRequest-400611810-20180705-224946

Failure type Failing test case Changed file by AstorJKali
org.opentest4j.AssertionFailedError TestRequest.java Request.java
  • Kali patch:
--- /src/main/java/com/http/Request.java
+++ /src/main/java/com/http/Request.java
@@ -235,7 +235,6 @@
 		header.put("Accept-Encoding", "gzip, deflate, br");
 		header.put("Accept", "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8");
 		header.put("Connection", "Keep-Alive");
-		this.setHeader(header);
 	}
 
 	public java.lang.String getContent() {
  • Overview: The problem is related to a failure in the test case. Indeed, looking at the commit history of the project, the developer changed the test case to fix the problem.

  • Reason why the patch has been generated: jKali managed to create the patch because the test case doesn't check if the header is empty or not. Indeed, adding for example this instruction assertFalse(r.getHeader().isEmpty()); in the test method testStatusOK the patch generate from jKali doesn't work.

  • Useful information for the developer: The patch indicated that there is something strange with the header tested in the test case. If the developer knows that the test case is correct, she can focus on the test case to understand if it is correct or not.

  • Human fix:

From 35e068c4c53f25ee8df2108b02ee4b8b9cba27f9 Mon Sep 17 00:00:00 2001
From: jguyet <jguyet@student.42.fr>
Date: Thu, 5 Jul 2018 22:52:53 +0200
Subject: Update google test return code 302

---
 src/test/java/com/http/TestRequest.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/test/java/com/http/TestRequest.java b/src/test/java/com/http/TestRequest.java
index a0d5b94..b1ada21 100644
--- a/src/test/java/com/http/TestRequest.java
+++ b/src/test/java/com/http/TestRequest.java
@@ -14,7 +14,7 @@ public void testStatusOK() {
  		
  		r.setGET().setUrl("http://www.google.com").setProtocolHttp().setDefaultHeader();
  		r.execute();
- 		assertEquals(200, r.getStatusCode());
+ 		assertEquals(302, r.getStatusCode());
  	}
 	
 	@Test

jmrozanec-cron-utils-249918159-20170704-112646_bugonly

Failure type Failing test case Changed file by AstorJKali
java.lang.AssertionError Issue215Test.java BetweenDayOfWeekValueGenerator.java
  • Kali patch:
--- /src/main/java/com/cronutils/model/time/generator/BetweenDayOfWeekValueGenerator.java
+++ /src/main/java/com/cronutils/model/time/generator/BetweenDayOfWeekValueGenerator.java
@@ -20,10 +20,9 @@
 		com.cronutils.model.field.expression.Between between = ((com.cronutils.model.field.expression.Between) (cronField.getExpression()));
 		int from = ((java.lang.Integer) (between.getFrom().getValue()));
 		int to = ((java.lang.Integer) (between.getTo().getValue()));
-		while (from <= to) {
-			dowValidValues.add(from);
+		while (from <= to)
 			from += 1;
-		} 
+
 	}
 
 	@java.lang.Override
  • Overview: the problem is related to the implementation of the method isMatch. Indeed, looking at the commit history of the project, the developer changed this method to fix the bug. The test case fails because the expected date and the next date generated with the method nextExecution are not equal.

  • Reason why the patch has been generated:

  • Useful information for the developer:

  • Human fix:

diff --git a/src/main/java/com/cronutils/model/time/generator/BetweenDayOfWeekValueGenerator.java b/src/main/java/com/cronutils/model/time/generator/BetweenDayOfWeekValueGenerator.java
index dc392e0..1b71cc0 100644
--- a/src/main/java/com/cronutils/model/time/generator/BetweenDayOfWeekValueGenerator.java
+++ b/src/main/java/com/cronutils/model/time/generator/BetweenDayOfWeekValueGenerator.java
@@ -125,6 +125,19 @@ public int generatePreviousValue(int reference) throws NoSuchValueException {
 
 	@Override
 	public boolean isMatch(int value) {
-        return dowValidValues.contains(LocalDate.of(year, month, value).getDayOfWeek().getValue());
+        // DayOfWeek getValue returns 1 (Monday) - 7 (Sunday),
+        // so we should factor in the monday DoW used to generate
+        // the valid DoW values
+        int localDateDoW = LocalDate.of(year, month, value).getDayOfWeek().getValue();
+
+        // Sunday's value is mondayDoWValue-1 when generating the valid values
+        // Ex.
+        // cron4j 0(Sun)-6(Sat), mondayDoW = 1
+        // quartz 1(Sun)-7(Sat), mondayDoW = 2
+
+        // modulo 7 to convert Sunday from 7 to 0 and adjust to match the mondayDoWValue
+        int cronDoW = localDateDoW % 7 + (mondayDoWValue.getMondayDoWValue() - 1);
+
+        return dowValidValues.contains(cronDoW);
 	}
 }

Mistahmilla-SudokuSolver-372495757-20180428-211304

Failure type Failing test case Changed file by AstorJKali
java.lang.AssertionError NakedSubsetTest.java NakedSubset.java
--- /src/main/java/org/mistahmilla/sudoku/solvers/NakedSubset.java
+++ /src/main/java/org/mistahmilla/sudoku/solvers/NakedSubset.java
@@ -28,12 +28,12 @@
 								}
 							}
 						}
-						if (count >= 2) {
+						if (true) {
 							for (int x = section.getMinX(); x < section.getMaxX(); x++) {
 								for (int y = section.getMinY(); y < section.getMaxY(); y++) {
 									if (squares[x][y] != 'x') {
-										board.getSquare(x, y).removePossibleValue(a);
-										board.getSquare(x, y).removePossibleValue(b);
+										this.board.getSquare(x, y).removePossibleValue(a);
+										this.board.getSquare(x, y).removePossibleValue(b);
 									}
 								}
 							}
  • Overview:

  • Reason why the patch has been generated:

  • Useful information for the developer:

  • Human fix:

From 229c47bc92a84129548f5e079de9c10126dde064 Mon Sep 17 00:00:00 2001
From: Matt <miller@cycop.org>
Date: Sat, 28 Apr 2018 15:19:20 -0400
Subject: NakedSubset bug fix

---
 .../java/org/mistahmilla/sudoku/solvers/NakedSubset.java | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/src/main/java/org/mistahmilla/sudoku/solvers/NakedSubset.java b/src/main/java/org/mistahmilla/sudoku/solvers/NakedSubset.java
index 1fed9fb..cc7f3c7 100644
--- a/src/main/java/org/mistahmilla/sudoku/solvers/NakedSubset.java
+++ b/src/main/java/org/mistahmilla/sudoku/solvers/NakedSubset.java
@@ -19,13 +19,14 @@ public void eliminate(){
         //go through each square and identify squares that have the same
         for (int a = 1; a <=9; a++){
             for(int b = 1; b<=9; b++){
+
                 if (a!=b) {
                     for (int i = 0; i < bs.length; i++) {
                         squares = new char[9][9];
                         section = bs[i];
                         count = 0;
-                        for (int x = section.getMinX(); x < section.getMaxX(); x++) {
-                            for (int y = section.getMinY(); y < section.getMaxY(); y++) {
+                        for (int x = section.getMinX(); x <= section.getMaxX(); x++) {
+                            for (int y = section.getMinY(); y <= section.getMaxY(); y++) {
                                 if (board.getSquare(x, y).getPossibleValues().contains(Integer.valueOf(a))
                                         && board.getSquare(x, y).getPossibleValues().contains(Integer.valueOf(b))
                                         && board.getSquare(x, y).getPossibleValues().size() == 2) {
@@ -35,8 +36,8 @@ public void eliminate(){
                             }
                         }
                         if (count >= 2) {
-                            for (int x = section.getMinX(); x < section.getMaxX(); x++) {
-                                for (int y = section.getMinY(); y < section.getMaxY(); y++) {
+                            for (int x = section.getMinX(); x <= section.getMaxX(); x++) {
+                                for (int y = section.getMinY(); y <= section.getMaxY(); y++) {
                                     if (squares[x][y] != 'x') {
                                         board.getSquare(x, y).removePossibleValue(a);
                                         board.getSquare(x, y).removePossibleValue(b);

MPI-ExperimentGroup-ExperimentTemplate-384776966-20180528-170150

Failure type Failing test case Changed file by AstorJKali
java.lang.AssertionError AudioAsStimuliProviderTest.java RandomIndexing.java

(There are different changes, so it is necessary to find which is the one that fixes the build)

  • Kali patch:
--- /src/main/java/nl/mpi/tg/eg/frinex/adaptivevocabularyassessment/client/RandomIndexing.java
+++ /src/main/java/nl/mpi/tg/eg/frinex/adaptivevocabularyassessment/client/RandomIndexing.java
@@ -68,7 +68,6 @@
 				int offset = offsetBuffer.get(indOffset);
 				retVal.add((i * blockSize) + offset);
 				offsetBuffer.remove(new java.lang.Integer(offset));
-				offsetBuffer.remove(new java.lang.Integer(offset - 1));
 				offsetBuffer.remove(new java.lang.Integer(offset + 1));
 			}
 		}
  • Overview:
  • Reason why the patch has been generated:
  • Useful information for the developer:

nablarch-nablarch-example-http-messaging-361036711-20180402-045142

Failure type Failing test case Changed file by AstorJKali
org.junit.ComparisonFailure ProjectSaveActionRequestTest.java ProjectSaveAction.java
--- /src/main/java/com/nablarch/example/action/ProjectSaveAction.java
+++ /src/main/java/com/nablarch/example/action/ProjectSaveAction.java
@@ -17,7 +17,7 @@
 	protected nablarch.fw.messaging.ResponseMessage onError(java.lang.Throwable e, nablarch.fw.messaging.RequestMessage requestMessage, nablarch.fw.ExecutionContext context) {
 		requestMessage.setFormatterOfReply(com.nablarch.example.action.ProjectSaveAction.createFormatter());
 		java.lang.String statusCode = java.lang.String.valueOf(nablarch.fw.web.HttpResponse.Status.INTERNAL_SERVER_ERROR.getStatusCode());
-		if (e instanceof nablarch.core.message.ApplicationException) {
+		if (true) {
 			statusCode = java.lang.String.valueOf(nablarch.fw.web.HttpResponse.Status.BAD_REQUEST.getStatusCode());
 		}
 		java.util.Map<java.lang.String, java.lang.String> map = new java.util.HashMap<>();
  • Overview:
  • Reason why the patch has been generated:
  • Useful information for the developer:

OpenFeign-feign-413754623-20180808-215547

Failure type Failing test case Changed file by AstorJKali
java.lang.AssertionError JAXBCodecTest.java JAXBDecoder.java

The reason of failure is different (here, there is an error about the version of Java used, but the error in the reality was another one).

  • Kali patch:
--- /src/main/java/feign/jaxb/JAXBDecoder.java
+++ /src/main/java/feign/jaxb/JAXBDecoder.java
@@ -24,7 +24,7 @@
 		if (response.body() == null)
 			return null;
 
-		if (type instanceof java.lang.reflect.ParameterizedType) {
+		if (false) {
 			java.lang.reflect.ParameterizedType ptype = ((java.lang.reflect.ParameterizedType) (type));
 			type = ptype.getRawType();
 		}
  • Overview:
  • Reason why the patch has been generated:
  • Useful information for the developer:

opentracing-contrib-java-hazelcast-390335750-20180610-103253

Failure type Failure details Failing test case Changed file by AstorJKali
java.lang.AssertionError java.lang.AssertionError: expected:<4> but was:<5> TracingTest.java TracingEntryBackupProcessor.java
  • Kali patch:
--- /src/main/java/io/opentracing/contrib/hazelcast/TracingEntryBackupProcessor.java
+++ /src/main/java/io/opentracing/contrib/hazelcast/TracingEntryBackupProcessor.java
@@ -20,7 +20,6 @@
 		io.opentracing.Span span = io.opentracing.contrib.hazelcast.TracingHelper.buildSpan("process", parent, traceWithActiveSpanOnly);
 		span.setTag("entryBackupProcessor", io.opentracing.contrib.hazelcast.TracingHelper.nullableClass(entryBackupProcessor));
 		span.setTag("entry", io.opentracing.contrib.hazelcast.TracingHelper.nullable(entry));
-		io.opentracing.contrib.hazelcast.TracingHelper.decorateAction(() -> entryBackupProcessor.processBackup(entry), span);
 	}
 }
  • Overview: the problem is related to the test case that checks the size of a List of MockSpan. Indeed, looking at the commit history of the project, the developer changed the test case to fix the bug. In particular, looking at the commit history of the pull request, the developer restored the previous version of the test case.

  • Reason why the patch has been generated:

  • Useful information for the developer:

  • Human fix:

diff --git a/src/test/java/io/opentracing/contrib/hazelcast/TracingTest.java b/src/test/java/io/opentracing/contrib/hazelcast/TracingTest.java
index 53574a9..e44b260 100644
--- a/src/test/java/io/opentracing/contrib/hazelcast/TracingTest.java
+++ b/src/test/java/io/opentracing/contrib/hazelcast/TracingTest.java
@@ -101,7 +101,7 @@ public void testEntryProcessor() {
     map.executeOnKey("key", new TestEntryProcessor());
     System.out.println("new value:" + map.get("key"));
     List<MockSpan> spans = tracer.finishedSpans();
-    assertEquals(4, spans.size());
+    assertEquals(5, spans.size());
     checkSpans(spans);
     assertNull(tracer.activeSpan());
   }

pac4j-pac4j-322406277-20171228-030236_bugonly

Failure type Failure details Failing test case Changed file by AstorJKali
java.lang.AssertionError java.lang.AssertionError: expected null, but was:<true> StringConverterTests.java StringConverter.java
  • Kali patch:
--- /src/main/java/org/pac4j/core/profile/converter/StringConverter.java
+++ /src/main/java/org/pac4j/core/profile/converter/StringConverter.java
@@ -8,7 +8,7 @@
 
 	@java.lang.Override
 	protected java.lang.String internalConvert(final java.lang.Object attribute) {
-		if (null != attribute) {
+		if (false) {
 			return attribute.toString();
 		} else {
 			return null;
  • Overview: The problem is related to the method internalConverter, whose override has been done in the failing commit. This commit belongs to a pull request that has not been accepted. Indeed, removing the override of this method, the program passes all the test cases.
  • Reason why the patch has been generated: AstorJKali managed to create a patch because it removes this return statement in the method internalConverter, and so the method returns null as the test case expects. This is the correct behaviour. Indeed, removing this return statement, the method returns null as the superclass AbstractAttributeConverter method does.
  • Useful information for the developer: The Kali patch changed the piece of code added in the commit that changed the status of build from passed to failed. This means that the patch allows the developer to focus direclty on the new piece of code to understand which is the error. In this specific case, the change has not been accepted, so it is correct to remove the functionality.

ryhita-gilded-rose-349620528-20180306-041741

Failure type Failure details Failing test case Changed file by AstorJKali
java.lang.AssertionError java.lang.AssertionError: expected:<12> but was:<13> ItemTest.java BackstagePassesItem.java
  • Kali patch:
--- /src/main/java/fr/esiea/BackstagePassesItem.java
+++ /src/main/java/fr/esiea/BackstagePassesItem.java
@@ -15,11 +15,11 @@
 				quality++;
 
 		}
-		if (this.sellIn < 6)
+		if (false) {

 		if(this.quality < MAX_QUALITY)
				quality ++;
  • Overview: the problem is related to the test case that checks the correct behavior of the method updateQuality. Indeed, in a later commit, the developer changed the test case to fix the problem. In the commit associated with the failing build, the developer changed two values of the test case that failed, and one of this has been changed in the commit that fixed the bug.
  • Reason why the patch has been generated: AstorJKali managed to create a patch because the failing test case had an error in the comparison of the quality values. Since the patch removes a piece of code that increments the value of that property, during the comparison the value got by the method updateQuality is the same that the text case expected, and so the test case passes.
  • Useful information for the developer: the developer can focus on the method updateQuality and checks if it is correct or not, and she can also check if the test that verifies its correctness is correct. Moreover, since the failing commit had only changes in the test case that then started to fail, she knows directly which is the test case that should be verified.

-Human fix:

diff --git a/src/test/java/fr/esiea/ItemTest.java b/src/test/java/fr/esiea/ItemTest.java
index c9d6737..ec41dfa 100644
--- a/src/test/java/fr/esiea/ItemTest.java
+++ b/src/test/java/fr/esiea/ItemTest.java
@@ -32,7 +32,7 @@ public void updateItemTest(){
      		items[i].updateQuality();
      	assertEquals(12, items[0].quality);
     	assertEquals(22, items[1].quality);
-   		assertEquals(12, items[2].quality);
+   		assertEquals(13, items[2].quality);
     	assertEquals(0, items[3].quality);
     	assertEquals(0, items[4].quality);
     }

swissquote-carnotzet-351211949-20180309-095950

Failure type Failing test case Changed file by AstorJKali
java.lang.AssertionError DefaultCommandRunnerTest.java DefaultCommandRunner.java
  • Kali patch:
--- /src/main/java/com/github/swissquote/carnotzet/core/runtime/DefaultCommandRunner.java
+++ /src/main/java/com/github/swissquote/carnotzet/core/runtime/DefaultCommandRunner.java
@@ -67,7 +67,6 @@
 			java.lang.Process p = pb.start();
 			p.waitFor();
 			java.lang.String output = org.apache.commons.io.FileUtils.readFileToString(tmp);
-			output = output.trim();
 			if (p.exitValue() != 0) {
 				throw new java.lang.RuntimeException((((("External command [" + com.google.common.base.Joiner.on(" ").join(command)) + "] exited with [") + p.exitValue()) + "], output: ") + output);
 			}
  • Overview: The build fails after introducing an instruction to trim the output, but the test case has not been updtated to support this change.

  • Reason why the patch has been generated: jKali manages to create a Kali patch because it removes exactly the instruction that makes the build fail.

  • Useful information for the developer:

  • Human fix:

diff --git a/core/src/test/java/com/github/swissquote/cartnotzet/core/runtime/DefaultCommandRunnerTest.java b/core/src/test/java/com/github/swissquote/cartnotzet/core/runtime/DefaultCommandRunnerTest.java
index 88fb2d0..a2bf241 100644
--- a/core/src/test/java/com/github/swissquote/cartnotzet/core/runtime/DefaultCommandRunnerTest.java
+++ b/core/src/test/java/com/github/swissquote/cartnotzet/core/runtime/DefaultCommandRunnerTest.java
@@ -33,7 +33,7 @@ public void test_large_output() throws Exception {
 				2, TimeUnit.SECONDS, true);
 
 		// Then
-		Assert.assertThat(actual, Is.is(expected));
+		Assert.assertThat(actual, Is.is(expected.trim()));
 	}
 
 }

timmolter-XChange-301755888-20171114-043126_bugonly

Failure type Failure details Failing test case Changed file by AstorJKali
java.lang.AssertionError expected:<227.38[97]6> but was:<227.38[58]6> QuoineAdaptersTest.java KrakenAdapters.java
--- /src/main/java/org/knowm/xchange/kraken/KrakenAdapters.java
+++ /src/main/java/org/knowm/xchange/kraken/KrakenAdapters.java
@@ -175,11 +175,6 @@
 		}
 		java.util.Map<org.knowm.xchange.currency.Currency, org.knowm.xchange.dto.meta.CurrencyMetaData> currencies = new java.util.HashMap<>();
 		currencies.putAll(originalMetaData.getCurrencies());
-		for (java.lang.String krakenAssetCode : krakenAssets.keySet()) {
-			org.knowm.xchange.kraken.dto.marketdata.KrakenAsset krakenAsset = krakenAssets.get(krakenAssetCode);
-			org.knowm.xchange.currency.Currency currencyCode = org.knowm.xchange.kraken.KrakenAdapters.adaptCurrency(krakenAssetCode);
-			currencies.put(currencyCode, new org.knowm.xchange.dto.meta.CurrencyMetaData(krakenAsset.getScale()));
-		}
 		return new org.knowm.xchange.dto.meta.ExchangeMetaData(pairs, currencies, originalMetaData == null ? null : originalMetaData.getPublicRateLimits(), originalMetaData == null ? null : originalMetaData.getPrivateRateLimits(), originalMetaData == null ? null : originalMetaData.isShareRateLimits());
 	}
  • Overview: Failing test case is different from the one fixed by the developer. The Kali patch doesn't work.

  • Reason why the patch has been generated:

  • Useful information for the developer:

  • Human fix:

diff --git a/xchange-quoine/src/test/java/org/knowm/xchange/quoine/dto/QuoineAdaptersTest.java b/xchange-quoine/src/test/java/org/knowm/xchange/quoine/dto/QuoineAdaptersTest.java
index e0df7b23d1..1f9830a061 100644
--- a/xchange-quoine/src/test/java/org/knowm/xchange/quoine/dto/QuoineAdaptersTest.java
+++ b/xchange-quoine/src/test/java/org/knowm/xchange/quoine/dto/QuoineAdaptersTest.java
@@ -42,7 +42,7 @@ public void testAdaptTicker() throws IOException {
     // Verify that the example data was unmarshalled correctly
     assertThat(ticker.getAsk()).isEqualTo(new BigDecimal("227.09383"));
     assertThat(ticker.getBid()).isEqualTo(new BigDecimal("226.78383"));
-    assertThat(ticker.getLast()).isEqualTo(new BigDecimal("227.38976"));
+    assertThat(ticker.getLast()).isEqualTo(new BigDecimal("227.38586"));
     assertThat(ticker.getVolume()).isEqualTo(new BigDecimal("0.16"));
     assertThat(ticker.getCurrencyPair()).isEqualTo(CurrencyPair.BTC_USD);
   }

usgs-volcano-core-408694507-20180726-231401

Failure type Failure details Failing test case Changed file by AstorJKali
java.lang.AssertionError Expected exception: com.martiansoftware.jsap.ParseException ScnlParserTest.java Scnl.java
  • Kali patch:
--- /src/main/java/gov/usgs/volcanoes/core/data/Scnl.java
+++ /src/main/java/gov/usgs/volcanoes/core/data/Scnl.java
@@ -82,7 +82,6 @@
 
 	public static gov.usgs.volcanoes.core.data.Scnl parse(java.lang.String scnlString) throws gov.usgs.volcanoes.core.util.UtilException {
 		if (scnlString.indexOf("$") == (-1)) {
-			return gov.usgs.volcanoes.core.data.Scnl.parse(scnlString, " ");
 		}
 		return gov.usgs.volcanoes.core.data.Scnl.parse(scnlString, gov.usgs.volcanoes.core.data.Scnl.DELIMITER);
 	}
  • Overview: The test case fails because it expects an execption, but it doesn't occur. The test case fails after the developer introduced a piece of code to handle cases when delimiter is a space. Since, she didn't update the test case to support this new feature, the test case fails. Indeed, looking at the commit history of the project, the developer changed the test case to fix the problem.
  • Reason why the patch has been generated: AstorJKali managed to create the patch because it deleted the return instruction introduced by developer in the last commit to handle the case in which the space is a delimiter. In this way, the program doesn't actually test the input with space as delimiter, but it uses the $ delimiter already present in the previous version of the program. Since the input string doesn't contain the symbol $, the program enters in this branch, and it throws the exception, making passing the test case.
  • Useful information for the developer: the Kali patch removed exaclty the return statement added in the commit that changed the status of build from passing to failing. Since this return statement contains the call to the parsing method using space ad delimiter, the developer can check if the problem is related to the logic of method that doesn't manage property this case or if the problem is in the input of the test case.
  • Human fix:
diff --git a/src/test/java/gov/usgs/volcanoes/core/args/parser/ScnlParserTest.java b/src/test/java/gov/usgs/volcanoes/core/args/parser/ScnlParserTest.java
index 0b603de6..2eab1105 100644
--- a/src/test/java/gov/usgs/volcanoes/core/args/parser/ScnlParserTest.java
+++ b/src/test/java/gov/usgs/volcanoes/core/args/parser/ScnlParserTest.java
@@ -2,13 +2,11 @@
 
 import static org.junit.Assert.assertEquals;
 
-import org.junit.Test;
-
 import com.martiansoftware.jsap.ParseException;
 
-import gov.usgs.volcanoes.core.args.parser.ScnlParser;
 import gov.usgs.volcanoes.core.data.Scnl;
-import gov.usgs.volcanoes.core.data.ScnlTest;
+
+import org.junit.Test;
 
 /**
  * 
@@ -65,6 +63,6 @@ public void when_givenScn_return_scn() throws ParseException {
    */
   @Test(expected = ParseException.class)
   public void when_givenBadScnl_then_throwHelpfulException() throws ParseException {
-    parser.parse("not a SCNL");
+    parser.parse("not-a-SCNL");
   }
 }

apache-incubator-dubbo-403447416-20180713-102123

--- /src/main/java/org/apache/dubbo/registry/multicast/MulticastRegistry.java
+++ /src/main/java/org/apache/dubbo/registry/multicast/MulticastRegistry.java
@@ -145,7 +145,7 @@
 	}
 
 	private void receive(java.lang.String msg, java.net.InetSocketAddress remoteAddress) {
-		if (org.apache.dubbo.registry.multicast.MulticastRegistry.logger.isInfoEnabled()) {
+		if (true) {
 			org.apache.dubbo.registry.multicast.MulticastRegistry.logger.info((("Receive multicast message: " + msg) + " from ") + remoteAddress);
 		}
 		if (msg.startsWith(org.apache.dubbo.common.Constants.REGISTER)) {

apache-incubator-dubbo-415750114-20180814-073311

Failure type Failing test case Changed file by AstorJKali
org.junit.ComparisonFailure MulticastRegistryTest.java MulticastRegistry.java
  • Kali patch
--- /src/main/java/org/apache/dubbo/registry/multicast/MulticastRegistry.java
+++ /src/main/java/org/apache/dubbo/registry/multicast/MulticastRegistry.java
@@ -348,7 +348,7 @@
 				urls.addAll(cacheUrls);
 			}
 		}
-		if (urls.isEmpty()) {
+		if (true) {
 			for (org.apache.dubbo.common.URL u : getRegistered()) {
 				if (org.apache.dubbo.common.utils.UrlUtils.isMatch(url, u)) {
 					urls.add(u);

Overview: The pull request has been closed, so the developes didn't accept the proposed change. Reason why the patch has been generated: Useful information for the developer:

eclipse-ditto-402096641-20180710-102844

eclipse-ditto-407599059-20180724-213504

santanusinha-dropwizard-db-sharding-bundle-415477949-20180813-165531

Failure type Failure details Failing test case Changed file by AstorJKali
java.lang.AssertionError Should have errored out ShardManagerTest DBShardingBundle
  • Kali patch:
--- /src/main/java/io/dropwizard/sharding/DBShardingBundle.java
+++ /src/main/java/io/dropwizard/sharding/DBShardingBundle.java
@@ -65,7 +65,6 @@
 	public void run(T configuration, io.dropwizard.setup.Environment environment) {
 		sessionFactories = shardBundles.stream().map(io.dropwizard.hibernate.HibernateBundle::getSessionFactory).collect(java.util.stream.Collectors.toList());
 		environment.admin().addTask(new io.dropwizard.sharding.admin.BlacklistShardTask(shardManager));
-		environment.admin().addTask(new io.dropwizard.sharding.admin.UnblacklistShardTask(shardManager));
 	}
 
 	@java.lang.Override

About

No description, website, or topics provided.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published