agile soul

Agile, agile, agile and more agile! Are those programmers beach body ready yet?

New fancy mac-pros, sushi for lunch everyday, the cool managers wearing shorts and tie on summer, all the walls in the co-work space decorated with gratifies, etc...

That definitely sounds much more fun than the office of many of us working in the corporate world. Who wouldn't like to work in such environment ... ;p
But is there anything else apart of those things that really makes your team an awesome agile team?

We know well that agile its about the feedback loops and there are a huge amount of books written on the topic, practices, principles, etc... So in order to put in practice an agile development style, what kind of characteristics should the team have? In my opinion there is an expense list of characteristics that the best agile teams have. Let's  a look at some of them:

Communicative
There is nothing worse than being in a non communicative team. It is essential for the agile team to communicate both internal and external whenever is necessary regardless if the current task in hands have to wait for a clarification. The team leader or the business analyst are not postman that carry messages outside of the team. Also agile teams and agile developers don't hesitate or doubt when they have to say something to somebody and they are not afraid of making a critic or taking a critic.

Transparency
For the agile team every aspect of their daily work its 100% accessible to everybody. There is no place for secrets. Everybody knows everything about everybody. Business roadmap, planed stories, passwords, colleagues salary... Absolute transparency is the best to build trust and cooperation.

Cooperative
There is no mine or yours for the agile developers. We are all in the same ship and we work based on 100% consensus agreement basis. We not just help each other and do pair-programming, we also swarm with other members of our team or even other teams, no matter how big the current priority is. Team building is more important than the business itself, we do not hesitate if we have to stop what we are doing and swarm with testers, analyst, architects, junior team members or anybody that needs a hand.

Fearless
Agile teams are well known for their incredible capacity to spike, prototype and challenge everyone and everything. There is no process, language, task or challenge that can stop the agile teams.

Experts
Due to its role diversity and multidisciplinary nature, agile teams have huge experience in what they do. The redirection that characterises agile teams gives space for every member to gain experience in any field that is needed or they have interest in. The agile team members enjoy and are always eager to learn new things no matter if it is outside of their comfort zones.

Solid relationships
When it comes to relationships between team members, there is no just silly small talks next to the coffee machine. Team building its something very important in the agile culture and doing all sort of team activities(e.g night outs, sports, quests, hobbies...) out of the office it is important for the agile team. To be able to enjoy being with each other in the office, we have to be able to enjoy being able to be with each other also outside of the office.

Effective self management process
Even if the agile team culture in occasions gives the impression of being laid back and informal, the process that governs the daily work its very well understood and defined by everybody. The difference between agile management and the old school command and control management is that in the agile everybody natural finds its place and knows what to do without the necessity of being told by a manager.

Context aware
Sceptics sometimes believe that agile teams are not aware enough about what are the priorities for the business. That they only care about their cool development tools, clean-coding and having fun while developing whatever they want. But it is not like this at all, sometimes agile teams are more aware about the business than the business itself. The agile company is a better prepared company to compete in the market than the non agile one. This is due to the multi-directional capacity that exists when having self-directed teams.


Agile practices and culture keep evolving. From the first ones who wrote the agile manifesto, to the most radical practitioners , everybody agrees that agile teams, are changing the industry for good.

How to verify that void methods were called using Mockito

You can also read this article in our brand new medium space. Click here!  Remember follow Javing on medium to make sure you don't miss out on some of the great new upcoming content.

Mockito is one of the most popular mocking frameworks for java.
This post Is just little miscellaneous where I will show you how to mock and verify a void method call.

Sometimes when we test a call to a void method all we want to do is just make sure that at some point in its life cycle, another method will be called with certain parameters.
Let's see the following example:

 public class SomeClass {  
      private OtherClass otherClass;  
     
      public SomeClass(OtherClass otherClass) {  
           this.otherClass = otherClass;  
      }  
      protected void firstMethod(int value) {  
           if(value > 0) {  
                secondMethod("Yes!");  
           }  
           else {  
                secondMethod("No!");  
           }  
      }  
      private void secondMethod(String value) {  
           otherClass.someMethod(value);  
      }       
 }  

In the above piece of legacy code the most important part is a method called "someMethod()". We must make sure that it is called in a proper way, but unfortunately it belongs to a dependency to which we have no access and also to make it more complicated it is inside a private method.

Mockito framework could help us mock and verify that method call.
Here is how we can do it:

 package demo;
 import static org.mockito.Mockito.verify;  
 import org.junit.Before;  
 import org.junit.Test;  
 import org.mockito.Mock;  
 import org.mockito.MockitoAnnotations;  
 import code.OtherClass;  
 import code.SomeClass;  
 public class TestClass {  
      @Mock  
      private OtherClass otherClass;  
      //Class under test  
      private SomeClass someClass;  
      @Before  
      public void prepareDependencies() {  
           MockitoAnnotations.initMocks(this);       
           someClass = new SomeClass(otherClass);  
      }  
      @Test  
      public void is_the_value_greater_than_zero() {  
           someClass.firstMethod(8);  
           verify(otherClass).someMethod("Yes!");  
      }  
      @Test  
      public void is_the_value_smaller_than_zero() {  
           someClass.firstMethod(-1);  
           verify(otherClass).someMethod("No!");  
      }  
 }  

The most important things to highlight in this test class are:

• The class under test is never mocked.
• The dependencies of the class under test need to be mocked.
• By calling a method on a mock object we will mock that method call
• By using the verify() method we will test that at some point the method from the mock was called  with the exact same parameters.
• The test class can access the protected method because the package name is the same.(But of course in your project structure test will be under src/test/java and production code under src/main/java)