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

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... :(

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

Having fun with RxJava

Outside in TDD

https://www.youtube.com/watch?v=XHnuMjah6ps

We will add our exceptions to the enum.

Testing IV

We are in position of testing exceptions like IV.
Exceptions will be added to enum and our algorithm we will keep working.

Removing duplicated loop.

Two loops were doing the same (appending letters)

Writing test for XXX requires a while loop

Duplication: there is two loops appending letters, we want to remove one because
both of them are doing the same.

Removing duplications.

We need to map X and V to numbers. We achive it by means of an enum.

Writing test for XVIII

We see duplications again :)

Writing test for X

Writing test for VII

Testing another simple case, V

We skip IV because it is an exception.

tripservice: link to youtube tutorial

Generalize code.

From duplications we identify pattern and generalize our code.

Again we write the simplest thing to make our test green

And we see duplications :)

We always write the simplest thing to make our test green

RomanNumeralGenerator, first test passing

RomanNumeralGenerator, creating test (first) and class (second)

romannumerals

different projects for codurance

new projects, tdd and sandomancuso

README file

TripService we can refactor as much as we want because everything is under test.

Creating validate method.

Required dependency for @Inject

TripServiceShould green

TripService is green again, we are using BDDMockito (which integrates nicely with //given //when //then comments)
and we can delete code from our TripServiceShould unit test

return_friend_trips_when_users_are_friends fails

Now test is using my Mock but it keeps failing with a different error :)

return_friend_trips_when_users_are_friends stops working

When a test fails we have a reason for refactoring our legacy code!!!
In this case the problema is related to using the static method of TripDAO

TripDAO, always test before refactoring

We need a new method in order to be able to rewrite our legacy code.
At the very end this method will be the one used by our app.
The static method will dissapear after refactoring our whole app (what should be done carefully)

Removing loggedInUser from Test.

Less variables makes our code more simple.