Thursday, March 10, 2016

Mockito for better unit tests

Today I'm going to introduce you a very nice framework that allows you write good unit tests that cover only the parts of code that you want to test and stub all other dependencies .. but obviously in order to do that your code must be written in a testable way.

To know more about testability please refer to this wiki document.

Agenda
  • What is Mockito?
  • How to use it?
  • Example
What is Mockito?

Mockito is a framework that  allows you writing unit tests that only test your piece of code by mocking and stub all other components that your piece of code depends on.

In other words if you want to test your integration with other libs and components then its not unit test any more .. its called integration test which is not covered in this post.

How to use it?

You can configure mockito using maven or simply download the lib from here.

For maven configuration you can define the dependency in your pom.xml as here.

Example

Note: I will use junit in the following example and in case you are not familiar with junit please refer to this.

Let's start by a very simple example that you have a class that reads a comma separated String and return it as a List<String> .. It reads this String by calling another class CSVReader that can either read it from file/database/network .. so in case you want to test your class only without being dependant on the CSVLineReaderClass you should mock the reader class.

Why?

Usually when running unit tests you need to get rid of the overhead of setting up other dependencies and want to see how your class/function behaves not how others behave.

Implementation of CSVLineParser:


The unit test should look like this, and you can add more test cases :).



When you run the test cases you will see the nice green results which means that all cases have passed correctly.



When you do something wrong like this :) .. you will see the unit tests failing.

 



In fact that's really nice, its really safe when you or someone else in your team mistakenly does these kind of stupid issues, its better to catch it during development than catching it in pre-production or on production and embrasse yourself and your team :D.

Mockito has way more than this simple example, but as usual I like to introduce you with very small nice things and then you can continue reading and see other features of the framework :).

I hope you like it.


Sunday, October 18, 2015

Strong Connected Components

There are plenty of problems that could be solved by finding the set of strongly connected components of a directed graph ..

In this topic I will explain what is a Strongly Connected Component? and how to find the set of all Strongly Connected Components of a directed graph.


Strong Connected Components


A Strongly connected graph is a graph where each vertex could be visited from each other vertex of the graph, for example the following graph has 5 strongly connected components.



Algorithm to find SCC

 

One of the most famous algorithms that is used to find strongly connected components of a graph is known by the Kosaraju's algorithm. And It works as follows:
  • DFS all nodes and save visited nodes in a stack S, push node only when finishing visit to all connected nodes.
  • Inverse the original graph by reversing all arcs E(U, V) to be E(V, U) instead
  • Pop each vertex V in S and DFS to get the strongly connected component that contains V.

Problem

 

To try this problem before reading my solution please visit CodeForces.


Your city has n junctions. There are m one-way roads between the junctions. As a mayor of the city, you have to ensure the security of all the junctions.

To ensure the security, you have to build some police checkposts. Checkposts can only be built in a junction. A checkpost at junction i can protect junction j if either i = j or the police patrol car can go to j from i and then come back to i.

Building checkposts costs some money. As some areas of the city are more expensive than others, building checkpost at some junctions might cost more money than other junctions.

You have to determine the minimum possible money needed to ensure the security of all the junctions. Also you have to find the number of ways to ensure the security in minimum price and in addition in minimum number of checkposts. Two ways are different if any of the junctions contains a checkpost in one of them and do not contain in the other.

 

Input

 

In the first line, you will be given an integer n, number of junctions (1 ≤ n ≤ 105). In the next line, n space-separated integers will be given. The ith integer is the cost of building checkpost at the ith junction (costs will be non-negative and will not exceed 109).

The next line will contain an integer m (0 ≤ m ≤ 3·105). And each of the next m lines contains two integers ui and vi (1 ≤ ui, vi ≤ nu ≠ v). A pair ui, vi means, that there is a one-way road which goes from ui to vi. There will not be more than one road between two nodes in the same direction.

Output

 

Print two integers separated by spaces. The first one is the minimum possible money needed to ensure the security of all the junctions. And the second one is the number of ways you can ensure the security modulo 1000000007 (109 + 7).

 

Solution