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

sona java plugin: missing rule description

sonar-java-plugin: fixing profile name

sonar-java-plugin: check for mutable Spring Service instance fields

JPA: GET revisions, HTTP examples

SonarQube tryint to create a custom JavaScript plugin

(no success)

no time for comments

sonar java plugin: renaming packages

sonar-custom-java-plugin: renaming from HelloWorld to Custom

Sonarqube custom rules: custom plugin for JavaScript

SonarQube, custom Java rules.

Sonarqube simple rule: missing required CheckRegistrar

Sonarqube rule: improvements

sonarqube helloworld plugin, renaming group and artifact ids

sonarqube 5.6.1: trying to implement custom rule.

Based on SonarQube JavaPlugin.java implementation.

This is too complicated. It is taking me too much time...

Messing around with sonarqube

Getting ready for integration with Sonar (using Jacoco maven plugin)

Explanation about Spring overriding beans when running JUnit tests

Spring JPA: generic classes for implementing Controllers for revisions.

Servicies and entities. Following RESTHUB implementation.

Spring JPA: AdDescription revisions

Spring JPA: Spring REST interceptor

Spring JPA: spring-data-envers, serializing data