Hi Ham, I love this reference instance. I thought it was a nice challenge to try to figure out how to install and start docker on my laptop, but it might be nice to include the step in the readme! ;-) Cheers,

Elena

After the update the to openweathermap API, the /weather endpoint is not working. I think the reason is due to weather url.

In application.properties it is defined as:

weather.url = https://api.openweathermap.org/data/2.5/weather

And it is called in WeatherClient.java as:

var url = String.format("%s/data/2.5/weather?q=%s&appid=%s", weatherServiceUrl, CITY, weatherServiceApiKey);

The part /data/2.5/weather will be duplicated. A simple fix is to define it in application.properties as:

weather.url = https://api.openweathermap.org

After fixing it, the existing tests and the /weather endpoint were working for me.

By the way, is /src/main/resources/application-int.properties still used? It still contains a reference to the darksky API.

hi. Thanks for the interesting article about testing.

I was reading the following text from your article "I've defined H2 as a test dependency in the build.gradle file. The application.properties in the test directory doesn't define any spring.datasource properties. This tells Spring Data to use an in-memory database. As it finds H2 on the classpath it simply uses H2 when running our tests."

And I see the following:

1. in article h2 is presented as test dependency but actually on code I see in build.gradle runtimeOnly scope.
2. can you please explain why runtimeOnly 'com.h2database:h2' still works when I run PersonRepositoryIntegrationTest ? I thought that h2 is in runtime classpath and the test should fail due to dependencies. But it doesn't.

To make sure you don't run into any trouble (e.g. a corrupt state) it's always a good idea to remove any existing data before integration tests and e2e tests are executed.

From my experience it's a bit frustrating to do this in every test and for every entity that is handled by the tests, as you have to autowire each Repository and call the deleteAll() method. Fortunately there's SQL and Spring provides the @org.springframework.test.context.jdbc.Sql annotation, which allows you to execute SQL before a test.

So you can create a file containing nothing else than delete statements and have this executed before each test.

delete-all.sql

delete from Person;

SomeIntegrationTest.java

//... package, imports etc.

@Sql(scripts ="/delete-all.sql")
public class SomeIntegrationTest { }

From what I see, unfortunately, it is not possible to get an API Key from DarkSky anymore. They are no longer accepting new signups. Any idea of how can we fix this issue? Thanks!

Hi,
I am wondering if there is a test needed to test with actual REST end point apart from using mocking response (via WireMock) https://api.darksky.net/forecast. If some of the fields from response json has been removed or updated then how to verify with mock? Thanks.

I'm trying to figure out how to simply execute the test cases. I don't see a junit dependency with "test" scope. I've tried gradlew test and also through the IDE. What's the process to get the test cases going?

Attempts to run all the test cases directly from the IDE throw the following error:

In the readme port number is 1543 but as docker port it is different

Not sure why, but six of the tests fail.

org.mockito.exceptions.misusing.InvalidUseOfMatchersException

Exemple, misplaced or misused argument matcher detected here:
-> at example.ExampleControllerTest.shouldTellIfPersonIsUnknown(ExampleControllerTest.java:56)"

This method

@Test
  public void shouldTellIfPersonIsUnknown() throws Exception {
      given(personRepository.findByLastName(anyString())).willReturn(Optional.empty());

      var greeting = subject.hello("Pan");

      assertThat(greeting, is("Who is this 'Pan' you're talking about?"));
  }

Would be nice to have demo of how to integration test controllers when authentication is in play.

Hi Ham,

I'm making videos about the test reference, and I think it is a distraction that every time I clone the repository, I need to copy example.env to .env, source it, and start the database. For my audience, I want to be able to focus on the tests, not the setup. Is there a theoretical reason why these steps can't be in the gradle build? Thanks again for this--it is really helping us.

I think this is a known issue with Gradle, but a successful build for me always ends up at 80%. It might be reassuring if it got all the way done!

I'm pretty agnostic, plus I don't mind there being a diversion in the discussion for people to let off steam, but I'm wondering if Spring is necessary, in the big picture.