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.

Getting rid of getLoggedInUser() method

MVC, Model should know nothing about View.

Service is in Model layer, it should not be dealing with sessions (View)

TripService refactored

Getting rid of variable makes code easier.

There could be performance issues, but if there are not problems this code is better.

Using ternary operation

Getting rid of variables in legacy code is great.

It enables us to reuse methods.
Once we take away as many variables as posible we can remake optimizations.

Moving Guard Condition to the top

Inline isFriendsWith(user)

User isFriendsWith(user) method in TripService

isFriendsWith(user) method added to User

Moving UserBuilder to production code

Thoughts about Feature Envy and path to follow when refactoring legacy code

1. When writing tests for legacy code we go from shortest to deepest branches.
2. When refactoring legacy code (handmade modifications) we go from deepest to shortest branches (just the opposite)

Feauture envy: some class (TripService) wants to do some action that should be implemented by another class which we
are using to extract the data and perform some action. Data and action should be done by the same class (User)

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

Improvement with fluent interface for our test

We now have the legacy code under test. So now and not before we can refactor the legacy code.

Improvement with fluent interface for our test

Removing duplicated code

We must always turn static methods into protected ones.

It is the only way of testing them (without using PowerMockito and stuff like that)
Remember, every change in the legacy code must be done by the tools proviede by our IDE (Eclipse, InteliJ, etc)
you must never rewrite by hand the legacy code.

Removing duplicated code

We test the next branch.

Remember: the assert must match the unit test method's name!!
In this case, no trips must be returned.

Creating test for refactoring legacy code.

1. We may not change production code if not covered by tests.
2. Start testing the legacy code following the shortest branch.
3. We should not invoke more classes than the one being under test.
4. We try to create a fluent interface. If we are testing user is not logged in, our test must
set the value making the not logged in user (we will call it GUEST)
5. Making clear that the input parameter in getTripsByUser is useless for the Unit Test throw_an_exception_when_user_is_not_logged_in

Sandro Mancuso, tripservicekata.

spring-jpa, liquibase, examples about how to update change sets in database

STOMP: log4j2 improvements

Spring STOMP simple server: a few improvements

Spring JPA: missing Named annotation in a few Spring services

SonarQube custom plugins, little improvement

SonarQube custom JavaScript plugin, unit tests

SonarQube custom Java plugin, unit tests

sonar java plugin: unit tests

JPA project: maven site and Javadoc working

SonarQube JavaScript custom plugin, improvements in description

sonar JavaScript plugin: use always interfaces.

Otherwise problems with cast because implementations are loaded in different class loaders and my
plugin is not able to see the class loader where the instance was created :/

sonar JavaScript plugin: AngularJS $rootScope.$on detection

sonar Java plugin: no time for comments

sonar Java plugin: multiple improvements

sonar Java plugin, no time for comments

sonar JavaScript plugin: any class extending CustomJavaScriptRulesDefinition will be injected and used in JavaScriptSquidSensor.

So as in the Java plugin, I do not have to do anything :) Every time JavaScriptSquidSensor finds JavaScript code my rules will run.

sonar Java plugin: non required Sensor because we will be running whenever JavaSquidSensor runs

JavaSquidSensor calls CustomRulesCheckRegistrar

sonar custom Java plugin: some improvements

sonar custom java plugin: removing non required dependency