London School Vs Classical TDD

This is still a question for me. I have recently read again Martins Fowler article "Mocks aren't stubs" and then read Emily baches articles "tell dont ask".

One of things Emily mentions which I have experimented is the fact of not writen gold-plating code. It happens recently while developing the comparator. I have started developing the core classs "Comparator". I had to constantly remember myself that this class will not be called in certain way  because the button in the UI will be disabled if, for example, both policies are not entered. 
So I definetely see an advantage of working outside in from the requirements and write  just the code that does the job.

Action entitlement manager

In a call center application one of the key/core aspects is the user entitlements which determine given a user what can and cannot this user do.
Another reason for an action to be available can depend on the entity which that action belongs to. For example you might not to edit a policy if the policy is already closed.
So that's two different reasons to determine if action is available: the entitlement and the action entity or context in which the action is carried over. Its quite possible that these reason are handled in different ways. Entitlement failure, can be handled simply by hiding the functionality. While context failure can be handled with an informative error message.
Again is important to determine same simple error code object which allow to handle the failure in different ways.
Again this can fit within the generic validator, handler approach. Where a composed validator can be created, and them invoked by passing the handler which can be  composed one too;one generic handler which handles the failure hiding a parametrized form component. And one popup error message handler  which displays the failure message for the context failure.

Registering listeners into services

I have just finished what it could be one of my last developments in my current client, the false new business comparator. One screen which based on a renewal proposal and fnb proposal compares them and return a lost of the fields which are different. The design is an FnbComparator class which acts as the core  of this screen. This class has a fnbcomparator service which does job of getting the info from the db an compare it returning a list of differences.  The fnbComparator has a Compariaosn translator which transforms the service reaponses into calls to a listener, which is implementes by the displayer. The main class remains like this:
Displayer = new FnbComparatorDisplayer()

New FnbComparator(displayer,new FnbComparatorService(), new FnbComparatorTranslator(displayer)
Displayer and comparator have each other references to allow call backs.

Responsibilities remain like this:
FnbComparator displayer: allows the user to enter info and it triggers the behavior on the comparator main class.
FnbComparator: its the class which supports the screen behavior. Expose methods accordingly to the fields shown in the displayer. It does the validation and send messages back to a listener (the displayer in this case) with whether or not that operation succeed. 
There might be another way to look at his responsibilities; This class expose and interface which allows to set the correct information to compare two prp, and them expose the method compare. Each of this methods produces output messages to a class listener.  However notice how the interface its dictated by the neccesity of the screen:
Setfnb(fnb fnb)
Setrenewal(renewal renewal)
Setfnbbyprposalno(string prpno)
Compare()
Notice those methods support the selection of a renewal, selection of a fnb and the manual entering of the fnb number from the ui. So he is really acting as screen listener.
Comparator service
  In order to provide the screen support, the FnbComparator needs something that does the comparison, is clear this responsibility.
Notice an interesting thing this service returns a response to itscaller (FnbComparator) who is in charge of handling the response. He does it by using a response translator which allows yo hide the internals from the respond and it sends accordingly output messages (compared, unknownerror, different vehicles...) That means the respond error code system can change and we only have to change this class. It exchanges the error codes for output messages. That job is done  in the book 'growing objects orientated systems" by registering the translator within the chat (my comparator service).  This allows the FnbComparator remain ignorant from the fact that he needs a "servicerespondtranslator" combined with the service. Its not obvious that you need this translator to do that. It would be if the service ask for it.
This design of registering listeners seems emerging when we do outside in development. If youll start thinking from the inside out...
It seems useful when calling a service which can have multiple outputs. This way you can have one class which manages this outputs and converts them into messages creating a nice interface.
Other approach will the caller getting the response. This might bbe more the casa when the call returns more of a concrete answer, like a calculation, which then its used by the caller to calculate something else that you can assert on the final calculation.
However im this scenario the next step will be to enable or disable the buttons.  Which is not the responsabilty of the caller. So you'll have to create too many classes for this test.
One approach will be pass the displayer as a listener and asserts that the displayer calls some util action. Class. With an interface very specific like 'disable button compare'.  In this case given a service call you could test almost till the last step of the ui logic. As much fine grained are method in the ui as more logic you can test leaving only without testing the line of code which sets CSS class or calls the disabled. Method on the button
Bottom line is that testing state in ui is difficult and that's why we look for this mesage approach.

TDD - motivations

Ive been watching a few videos on this topic by Robert c Martin. His three laws are:

1. You are not allowed to write any production code unless it is to make a failing unit test pass.
2. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test.

He mentions the following "minor" reasons:
 - Halve your debugging time
 - Serve as documentation
 - Improve you designs
 - Its fun


Halve your Debugging time
 
Following the three rules you'll never be more than a minute away from knowing that  you code works. You can easily undo the last line you when something doesn't work

Serve As Documentation
Third party come with a pdf guide. What is the part that we really look at? The sample codes. Unit test are simple to understand, they show every possible way to invoke an API, and they are executable, so they are always in sync, they are the perfect documentation!!

Improve your design
Writting test after your works it's quite hard because the code is not testable, its too coupling to something, and its hard to break that coupling.
Following the laws you can't write production code that is hard to test, because you wrote the test first. "Your code is testable or decouple, simply by writing the test first you end up you wind up your production code in ways that you never thought before. You end up with a better design".

Its fun
Becuase the test fail and  you want to make it pass. You get to write a test and make it pass, write another test and make it pass...


Main reason
Bad code,
why do you write it? we have to go fast.

Why don't you clean it? How many times you look at a code and think I need to clean it, next thought is I don't want to break it?

You are scared from breaking it. If you break you own it. So you don't touch it. So system continues to get worse and worse, slowing you down, slowing your team down till eventually the project gets through away and fresh new project starts.

How do we get reed of that fear?
Imagine we have a button, and when you push it within a few seconds a green light will tell you everything works.

"If you have the button, you'll not be afraid of touch, if you touch it will get clean, if it gets clean the team will go faster and thats why we do it."

How is stupid is to be scared from the code write, how bad is to not make a change that improve you code,  how unprofesional?

The only way is to have a suite of test that you can trust. You can trust your unit test if test everything.

Code coverage tool?
The goal is a 100%. You can't reach it but we try to get as close as possible.







 

Practical object oriented -Sandi metz

I've finished today the book. Just to write a list of the top things within the book:
Asking for what instead of telling how
Seeking context independence
She uses the example of mechanics and Trip. Where a trip is prepare if its bikes are prepare. There are two knowledge levels here. One is  how to prepare a bike (pump the tires, check chain...). The other is how to prepare a trip. Which is by preparing each of his bikes. Both responsibilities correspond to the Mechanic. In order todo that a mechanic knows that a trip has bikes. But we could abstract this concept into a preparable , where something can be preparable is it has bikes. This avoids the preparing knowledge from leaking into the trip class.
Notice that in order to achieve this we have to different kinds of interfaces. On one side we have a mechanic (preparator), exposes command methods, which allow to tell the what not the how. But on the other we have something preparable, which responds to query methods.
I though that this kind of query concept was wrong, and was looking always for the command like concept.  However it does make sense in situation like this where preparing is domain heavy concept which needs to be extracted from bike AMD put into a service. Then the dilemma is whether trip passes bikes and makes the service more context independent (he doesn't works with something that has  bikes, he works with bikes directly). In this case the trip knows that are his bikes the thing that need Ti be prepare.
The other. Trip seems that. Still know that the bikes. Are prepare since  still needs to respond tio bikes as a preparable.
But un tje example mechanic ask for the bikes,vehicles and something else from the trip so it totally make sense to pass the wrapping object trip.

Remove argument order dependency with a has table

Inheritance
Decoupling subclasses using hook messages (post_initialise)
It removes. The super from subclasses and therefore the knowledge within the subclass of the superclass

Query versus command important for testing

Test Equality

Entities can not be compared as value objects
IEqualityComparer use it to compare entities in tests:

Helper method that sets a value and return the entity itself with the same values. It helps to create expectations when only one property changes

Resemblance
Create subclass which implements equals

Likeness
 

TDD a practical book: communication from View layer to Logical Layer

Just getting to the end of this book, I wanted to write about the interfaces which defined the communication between the view and the logical object, specially the information that the view passes to the logical layer and whether we should use finer interfaces with individual getters for each field (used by David in his book), to a coarse interface with one getter returning a data structure.

 Passing Simple fields accross
By simple fields, I mean fields that do not need validation,  an string, an integer an enumeration are considered a simple fields. However a decimal is not, since and decimal is built from a string but it needs validation to be built.

This approach has the advantage of leaving the view completely ignorant from any sort of logic. The logical object asks for each single simple fields to the view and them he builds an object or an entity, e.g. a movie, while he carries out the validation.

In this case the View is acting as both, a service (Movie displayer) and a view Model (the Movie). Mixing these two responsabilities can be a problem when we has multiple views of a movie. As well it can obscure the test verification phases, where seeing the the view as a service can make hard to implement the equality.

Passing a view Model (Interface segregation)
In this case the View acts as a display service (Movie displayer) of a View Model (the movie). Even thought the concrete view class can still acts as both we could separate the movie into its own interface.

In this case,  we can end up with a Movie view Model, and Movie logical object, very similar between them, but the first being a data structure while the second is an object with behaviour.  For example in the case of the movieView, the ratings, are a vector, while in the movie are an array. Another example will be an amount field, while in the view will be an string the object would have it as a decimal so easily implement operations on it.

This allows to narrow the movie view, in pretty much two methods: "displayMovie" and "getMovie", passing an Movie view Model, which can easily implement equality to help in test verification.

If the view model is shared by different view this approach make sense. The downside is that increments complexity by segregating a new interface which will have to be converted from and to the object.

Passing the object

Having the editor talking to the view using the objects can reduce complexity by using one only object (Movie).
The issue here, it is easy that logic leaks into the view, since building the logical object can easily require validation.


Conclusion


I believe the key here is avoid having logic within the view, specially validation.
Fields entered in the view will have to be validated before they form
The key here is when do we do the data validation captured on the view.
The other key will be how fine/coarse grain we will like our view interface.
The third one will be avoid complexity when not needed.

At the moment I would avoid the "Passing the object"  approach which is likely to break the first key.  I would start with "Passing simple Fields",  and I would refactor if needed into "Passing a view Model".