Using another gradle file for integTest task

Debugging H2 with TRACE_LEVEL_SYSTEM_OUT=3

Flyway, configuration example and thoughts :(

Update build.gradle

How to debug with H2

docker-compose-gradle-plugin requires docker-compose in PATH

Using random port from docker-compose-gradle-plugin

Renaming to spring-configuration-h2-test

Fixing time zones for WEST

Using docker-compose-gradle-plugin for integration tests

DDL: fixing timestamp default value and contraints

Integration test with docker-compose-rule

AdRespositoryShould, changing method names

Using H2 for data base integrationt tests

Right directory for Spring test files

Update to right dependencies

Fixing OneToMany and ManyToOne annotations

Also making work auditory for AdDescription :)

Integration test task

Fixing OneToMany and ManyToOne annotations

Also making work auditory for AdDescription :)

Improving test

Changing name of gradle project

A few improvements in my unit tests

Using jacoco

Giving names to my constraints

spring-jpa-persistence, using gradle

RxJavaCarControllerIntegrationTest, cleaning up imports

Removing time out from RxJavaAdapter

IMHO these kinds of time out should be defined by server adminitrators

Thoughts about Observable (stream), Single (one element), toList() and Spring

Spring can already work with CompletableFuture

No need of creating my own adapter :)
See: org.springframework.web.servlet.mvc.method.annotation.DeferredResultMethodReturnValueHandler.CompletionStageAdapter

Using Spring 4.3.4.RELEASE

Using RxJava 2.0

RxJavaCarControllerIntegrationTest

Update to RxJava 2.0

Using RxJava 2.0

Removing useless inner interface from Adapters

Fixing CallableCarController

CarControllerIntegrationTest

CompletableFutureCarControllerIntegrationTest

DeferredResult, exceptions handler

RxJava REST example

Creating async services relying on sync ones

No repeat yourself :)

Adapter for DeferredResult <-> CompletableFuture

RxJava, using method reference instead of lambdas

Playing with asynchronous requests in Spring

Possibilites:
Callable
Deferrable + CompletableFuture
Deferrable + ListenableFutureAdapter
RxJava

More about working with Promises in Java 8

NOTICE about parallelism and ForkJoinPool

Having fun with CompletableFuture AKA Promise in Java

Trying to understand ForkJoinPool

Do not forget Thread.currentThread().interrupt()

Also comments because I already forgot the difference between submit(Runnable) and submit(Callable)

Fixing coverage in Clock.today()

Ivan Lorenz solution.

Merge branch 'master' of https://github.com/gumartinm/JavaForFun

ClockGus.format(date) renaming method

ClockGus.formatted(date) renaming method

Merge branch 'master' of https://github.com/gumartinm/JavaForFun

Fixing coverage in Clock.today()

My implementation solves the coverage issue (hopefully it is right)

How to configure IDE Eclipse

We end up writing our application based on the acceptance test

PrintStatementeFeature requires the right values for clock.

BIG WARNING: Clock.today() is not under test!!!!

Our tests do not fail even if we return null from there...

Making StatementPrinter and StatementPrinterShould look better

StatementPrinter, test for print method green

StatementPrinterShould is failing for the right reasons.

The acceptance test is failing because we need to implement the print method in StatementPrinter.

We always write first a test and then the implementation.
In this case we have to create the test called StatementPrinterShould and from
there we can create the implementation for the print method.

Clock test is green.

Inline as much code as possible (getting ride of variables)
We isolate and control the randomness in our code.
No using spies, instead, we use private classes in our tests.

Clock test working but we need to control the random part.

We need it in order to write tests that will work in any day.

Renaming local variables in TransactionRepository

Removing duplications from TransactionRepositoryShould

Now we have a test for addWithdrawal

It is only left a test for addWithdrawal

Tests failing for the right reason

We need to keep implementing methods.

Tests are failing for the right reasons

They throw UnsupportedOperationException because we need the implementations.

We have a green test for AccountShould

But PrintStatementFeature is failing because the acceptance test is using
the real classes, it tells me what has not been implemented :)

AccountShould is failing for the right reasons.

We can now implement the printStatement method.

We have to test the printStatement method in Account

Delegating the responsability of storing transactions.

TransactionRepository will store transactions.

Creating test for Account.

Always write first your asserts.

Now we have test expecting some result, it is now failing for the right reasons.

We are using the double loop of unit testing:

* First, start with an acceptance test.
* Second, once the acceptance test is failing for the right reason then you
go to the inner loop of TDD (the unit test) we can start unit testing our code.
  Once we have all the classes under unit tests our accpetance test should go green.

Test throws UnsupportedOperationException as expected.

You should configure your IDE for throwing UnsupportedOperationException
whenever it automatically creates a method. In this way, when running
our unit tests we are able to find out what is not yet implemented.

We finish writing our test.

Writing the asserts and the trigger for those asserts.

First acceptance test

Use interfaces for representing the external world.

Acceptance test, README (constraints)

RxJava: using flatMap method

Dealing with InterruptedException, the right way.

Closing fd as it must be done in CustomHTTPClient

I feel ashame... :(

Having fun with RxJava

Fixing coverage in Clock.today()

My implementation solves the coverage issue (hopefully it is right)

How to configure IDE Eclipse

We end up writing our application based on the acceptance test

PrintStatementeFeature requires the right values for clock.

BIG WARNING: Clock.today() is not under test!!!!

Our tests do not fail even if we return null from there...

Making StatementPrinter and StatementPrinterShould look better

StatementPrinter, test for print method green

StatementPrinterShould is failing for the right reasons.

The acceptance test is failing because we need to implement the print method in StatementPrinter.

We always write first a test and then the implementation.
In this case we have to create the test called StatementPrinterShould and from
there we can create the implementation for the print method.

Clock test is green.

Inline as much code as possible (getting ride of variables)
We isolate and control the randomness in our code.
No using spies, instead, we use private classes in our tests.

Clock test working but we need to control the random part.

We need it in order to write tests that will work in any day.

Renaming local variables in TransactionRepository

Removing duplications from TransactionRepositoryShould

Now we have a test for addWithdrawal