Once the owner of a Quality Assurance business himself, Pradeep Arigue holds a Bachelors of Computer Applications, and has over 10 years’ experience in the industry. He first joined the IBS team in 2012 as a QA Analyst, eventually becoming QA Lead, and is now our QA Practice Manager.
Working onsite at client facilities in the US, Pradeep also manages the IBS offshore QA team based in Hyderabad India. When asked what he likes about working with IBS, Pradeep notes the work environment. “I love that there is always something new to learn. I consider myself very fortunate to work in a field that is always changing and growing with new technologies, capabilities and ideas.”
Initially from India, Pradeep first traveled to the US in 2014, making his 5th trip in September of 2018. Currently, he’s working with IBS’ insurance and finance clients, setting up their QA practices and creating automation proof of concepts. When he’s not researching the latest technologies, Pradeep enjoys playing cricket and seeking out the new best Thai and Mexican restaurants he can find!
Though a number of organizations and businesses have implemented some sort of QA practice into their development cycle, a large percentage of them still do not have a dedicated resource handling testing. This means they’re taking developers with a specialized skillset away from what they do best to focus on QA. While many organizations have incorporated agile into their development process, they have not done so in their QA process. Continue reading “Challenges Testing in Agile”→
The front-end testing I’ve done in the past has always had some friction with respect to getting the tools setup properly. Mostly I have used Jasmine as the testing framework, which is pretty self contained – but to get a node test server setup properly there are a variety of other npm modules and karma configuration settings to deal with. I previously wrote about how the angular-cli makes it easy to get an Angular 2 project setup, and this includes getting the test tools setup as well. So instead of dealing with configuration settings, you can quickly get to just writing tests.
Until recently, the front-end testing I’d done had not directly tested any Angular services. In almost every case, the $http calls in the services were just returning data from an API back to a controller. However, on a recent project I had a scenario where the data from the API had to have some filtering and permission logic applied before passing on the data. This was a case where unit testing the service made sense.
As it turns out, testing a service is very similar to testing a controller in terms of setting up the test, injecting dependencies, and making assertions. The only real difference is the need to mock the $http call in the service. To do this the angular-mocks library provides the $httpBackend tool. Let’s walk through an example of testing a service.
I was writing some tests for an Angular app and ran into a scenario where I needed a page to behave differently if the time of day was before or after 6AM. The logic is simple enough to capture in my controller:
vm.date = moment().subtract(6, 'hours').toDate();
Basically, if it is before 6AM, display the prior day, otherwise display today. However, as I was trying to write a test for this controller the problem came up: how do I take control of the current time to test both scenarios?
One of the features I like about Jasmine is that the ability to mock objects and do interaction based testing is built into the tool. When testing C# code (with NUnit, MSTest, or even NSpec) you have to pull in another tool to handle mocking.
In Jasmine, mock objects are called spies. Accordingly, there is a built-in function called spyOn, which takes two parameters:
A common rule of thumb is 80% code coverage. But I think the flaw with that metric is that it treats all areas of the code base with equal importance. For example, I would say that code for CRUD operations in the admin section (for example) is less important than the code that accepts customer payment and issues an insurance policy. In this case, it actually would matter a great deal which 20% of the code is not tested.