Implement your Test Strategy

Importance of having a Test Strategy

Testing is a cross-functional activity that involves the whole team, and should be done continuously from the beginning
of the project. Building quality in means writing automated tests at multiple levels (unit, component, and acceptance) and running them as part of the deployment pipeline, which is triggered every time a change is made to your application, its configuration, or the environment and software stack that it runs on. Manual testing is also an essential part of building quality in: Showcases, usability testing, and exploratory testing need to be done continuously throughout the project. Building quality in also means constantly working to improve your automated testing strategy.

The design of a testing strategy is primarily a process of identifying and prioritizing project risks and deciding what actions to take to mitigate them. A good testing strategy has many positive effects. Testing establishes confidence that the software is working as it should, which means fewer bugs, reduced support costs, and improved reputation. Testing also provides a constraint on the development process which encourages good development practices. A comprehensive automated test suite even provides the most complete and up-to-date form of application documentation, in the form of an executable specification not just of how the system should work, but also of how it actually does work.

Automate your software delivery

If a customer wants to add a feature/idea to a product, the time that it will take to release a feature to the market will depend upon the maturity of processes and practices employed by the software delivery team that works on it. The lesser time it takes, the better it is.

But, how can we reduce the time it takes to deliver software? What are the limitations of the traditional software delivery process? How can automating the various stages of software delivery process reduce time to market. In this post my attempt is to introduce the concept of Continuous Delivery, which in a nutshell is automate everything which you can in your software project. I will also list some of the anti patterns of software delivery. So, if you see any of these in your projects, I think you have an opportunity to improve. This post will the first in the series of posts that I am planning to write on Automated software delivery process. In the coming posts, I will discuss more concrete advice on various phases of software delivery lifecycle.

B-Tree Index in MySql

Indexes in MySql works like an index in a book. While, indexes in a book tell you about the pages on which a term occurs, indexes in MySql tell you the rows that contain the matching data. An index contains values from one or more columns in a table. If you index more than one column, the column order is very important, because MySQL can only search efficiently on a leftmost prefix of the index. Creating an index on two columns is not the same as creating two separate single-column indexes. In this post, I will discuss about B-Tree index and it’s working in MySql.

Why MongoDB?

A database is needed to persist the data of an application. We have been successfully using relational databases to do so. They are mature and well known. So, why use a new technology like document based database to store the web application data. Let’s explore the reasons by looking at the features of a commonly used document based databases, Mongodb. 

Git Rebase Explained

Using git rebase, you can rewrite the history of a repository in a variety of ways.

rebase takes a series of commits (normally a branch) and replays them on top of another commit (normally the last commit in another branch). The parent commit changes so all the commit IDs are recalculated. This can cause problems for other developers who have your code because the IDs don’t match up.

There’s a simple rule of thumb with git rebase: use it as much as you want on local commits. Once you’ve shared changes with another developer, the headache is generally not worth the trouble.

git rebase takes a branch (the most common use), a tag, or a commit ID to rebase on top of.You can also pass the –rebase option to git pull, causing it to perform a rebase instead of merging the upstream changes into your local branch.

git rebase requires a clean working tree—that is, a working tree with no modified files. If you have changes that you’re not ready to commit, you can stash them until you’re done.

A conflict might arise during the replaying of commits. Like a conflict during a regular merge, a conflict happens when two commits modify the same line of code. git rebase stops when this happens and asks you to fix the conflict and then continue.

You tell Git you’re ready with git rebase –continue.

You can also skip a commit that’s causing a conflict by calling git rebase –skip. That could lead to further conflicts, however.You can abort the rebase too with git rebase –abort.

There’s always a safety net if you need to undo a rebase after it’s completed. Git points ORIG_HEAD at the commit before major changes like git rebase are run.You can use git reset to reset your repository back to that original.

To rebase your current branch against master, use

git rebase master

The following image shows the organization of commits before and after a rebase.

 

Git: How to create a new Repository

Repositories in Git are stored on your local file system right alongside the code they track.You create a repository by typing git init in the directory that you want to start tracking files in.

There are two repositories in Git to collaborate with others: a private one and a public one. Private repository, is where you do all your work. It’s the repository with the working tree.

This two-tier system gives the ability to track local experimental changes while only sharing changes via your public repository that are ready for others to work with.

git init creates a .git directory in your current directory and initializes the Git repository inside that. Once the repository is initialized, we need to add (using git add) and commit (using git commit) the files in the repository.

With an initialized repository, you have a working tree that you can interact with. Working tree is the latest copy of the repository.

Create a repository.
prompt> mkdir test-repository
prompt> cd test-repository
prompt> git init

Add some files in the test-repository folder. To add and commit the files in the repository, use the following commands.

prompt> git add .
prompt> git commit -m “some commit message”

That’s it, with this commands, you have created a new repository and added few files in it.

In the next post on Git, I will discuss about cloning an existing repository into local machine.

Capturing methods arguments with Mockito

In my project, we developed an API for searching on the lines of Hibernate Restrictions API. It was for Solr search. A sample code looked something like

 public SearchResults searchApprovedRecipes(String searchText, Integer pageNum) {
 SolrSearchServiceImpl.PageCounter pageCounter = new SolrSearchServiceImpl.PageCounter(pageNum);

 SearchCriteria searchCriteria = new SearchCriteria(SearchCriteria.SearchType.RECIPE);
 searchCriteria.add(SearchCriteria.SearchField.NAME, searchText);
 searchCriteria.add(SearchCriteria.SearchField.STATUS, WorkflowStatus.APPROVED.name(), WorkflowStatus.EDITED.name());
 searchCriteria.setMaxResults(pageCounter.getMaxResults());
 searchCriteria.setStart(pageCounter.getStart());

 SearchResults searchResults = getRestTemplate().postForObject(getSearchUrl(), searchCriteria, SearchResults.class);

 return searchResults;

Now, if you talk about unit testing, there is nothing much to test, except mocking calls to rest template. The main purpose of this method is to build SearchCriteria. So, if somehow, we can mock SearchCriteria, then we could test that.

Mockito comes with a concept of capturing the arguments passed to the mocked calls (in this case, call to RestTemplate would be mocked), using ArgumentCaptor, which captures argument values for further assertion.

Following is the unit test case of the above method.

@Test
 public void testSearchApprovedRecipes() {
 ArgumentCaptor<SearchCriteria> searchCriteriaArgumentCaptor = ArgumentCaptor.forClass(SearchCriteria.class);
 String test = "test";
 solrSearchService.searchApprovedRecipes(test, 1);
 verify(restTemplate, times(1)).postForObject(eq(SEARCH_URL), searchCriteriaArgumentCaptor.capture(), eq(SearchResults.class));

SearchCriteria searchCriteria = searchCriteriaArgumentCaptor.getValue();
 Assert.assertEquals(2, searchCriteria.getSearchFields().size());
 Assert.assertEquals(SearchCriteria.SearchType.RECIPE, searchCriteria.getSearchType());
 Assert.assertEquals(test, searchCriteria.get(SearchCriteria.SearchField.NAME).get(0));
 Assert.assertTrue(searchCriteria.get(SearchCriteria.SearchField.STATUS).contains( WorkflowStatus.APPROVED.name()));
 Assert.assertTrue(searchCriteria.get(SearchCriteria.SearchField.STATUS).contains( WorkflowStatus.EDITED.name()));
 }

In the above code, you can see that first we created a ArgumentCaptor for the SearchCriteria class, and then, while mocking call to the RestTemplate, instead of passing the SearchCriteria object, we passed the ArgumentCaptor and all the changes made to the SearchCriteria inside the method are captured in the ArgumentCaptor. Now, once the method calls return, we can have assert statements against the ArgumentCaptor. This way, we can test the SearchCriteria.