Skip to main content

Agile Testing - A defense system from my team stories


Today, I love to tell you about my team story about testing. That started from no testing to extreme testing system.

 eXtreme Feedback Devices (https://jenkins.io/blog/2013/09/05/extreme-feedback-lamp-switch-gear-style/)
Guess what? That is really an exciting idea from the picture(no?). These devices can work with Jenkins. Whenever they build a Jenkins job, this system notifies instantly to developers the status of their system.


That is not 100% related to testing but somehow it is like our testing mindset. Because, in my team,  we call our testing system is a defense system :). There is no doubt that it is very hard for us to remember all features of our applications even which is developed for a long time. Like a document, tests help us make sure no features will be lost after changes such as adding new more features, fixing bugs or refactoring code.

That was the reason why we cared much about testing. It was really important for developing apps. Back then, we thought about how to test effectively.
Testing pyramid
The "testing pyramid" points out that basing on the efforts, the agility of detecting bugs and the running time, we chose what types of tests should be more concern. We mainly followed the above priority, unit test was the most concern.

Now, I am going to share about our problems that we already met and what our strategies were in order to overcome them.

Unit Test

We maintained several very old projects that contains no tests. We got a lot of bugs and we tried to fix them but the problem was no one knows these bugs will happen again or not. It looked like a non-stop loop for fixing bugs. Terrible!
Oh no!
That was a reason why we used unit test to make sure we wouldn't see the bugs already fixed again. Day by day, we practiced TDD and tried to improve our unit test a lot. We also used Hamcrest to make our testing code more readable.

Integration Test

In our application architecture, we called integration such as controller which was a place that contained the combination from business logic (be handled at Service layers), managing database (be handled at DAO layers) and user interfaces (UI) events.

Issue with mock at integration layer
With unit test, it makes sense that a layer can mock a tested layer. For example, DAOs is already covered and Services layer just mocks DAOs layer and just focus on testing its logic. We used Mockito to archive that.

However, some time our applications still work wrong even our unit tests are passed. Why? We figured out that the problem came from mocking when we integration a lot of things together. For instances, we have Services call DAOs, we mock DAOs when we test Services. Because we always assume the behavior of DAOs work correctly, we will soon get unexpected problems in Services if the implementation of DAOs is changed.

This issue led us to find a new type of test is more reasonable rather than unit test. We call it integration test. Here we simulated a real environment and work with real data connection instead of mocking.

GUI Test

We used Selenium in order to test behaviors of GUI such as GUI elements' validation and interaction. We faced to a problem that it takes time too much when running in multi-browsers manually. We found Sauce Labs can help us. It can work with Jenkins so we can automatically running our test as we want on cross platforms.

Selenium Grid (http://www.seleniumframework.com/intermediate-tutorial/what-is-selenium-grid/)
However, we met another problems with Sauce Labs that is very hard to match our Selenium browser drivers, our operation system (Window, Linux) versions with Sauce Labs provided options. We found a better way to go that is Selenium Grid. With Selenium Grid, we freely configure our browsers drivers and operation system versions, it has not only the same ability to Sauce Labs but also run faster thanks to local connection. Moreover, it is free. :)

Summary

Tests are very important for us to develop our applications. It likes our document and defense system. We should try to test as much as possible to reduce bugs and improve our products quality.

Yeah, that is all from my story. What about yours?

Comments

Popular posts from this blog

The HelloWorld example of JSF 2.2 with Myfaces

I just did by myself create a very simple app "HelloWorld" of JSF 2.2 with a concrete implementation Myfaces that we can use it later on for our further JSF trying out. I attached the source code link at the end part. Just follow these steps below: 1. Create a Maven project in Eclipse (Kepler) with a simple Java web application archetype "maven-archetype-webapp". Maven should be the best choice for managing the dependencies , so far. JSF is a web framework that is the reason why I chose the mentioned archetype for my example. 2. Import dependencies for JSF implementation - Myfaces (v2.2.10) into file pom.xml . The following code that is easy to find from  http://mvnrepository.com/  with key words "myfaces". <dependency> <groupId>org.apache.myfaces.core</groupId> <artifactId>myfaces-api</artifactId> <version>2.2.10</version> </dependency> <dependency> <groupId>org.apache.myfaces.core<...

Building a Wizard with Chain of Responsibility Pattern

What is the Idea? We want to create a page that there are some steps and each step has its own business. Users are able to click on a step and its status could be changed. Primefaces owns a component " Wizard " but it it quite hard for us in order to apply our very specific and complicated business domain logic on each step; even we cannot click on a step of this component. We somehow are able to use the component " TabView " works with a strong back-end mechanism. A backend mechanism! what do I mean? Yes, we need it because we want to abstract the behaviors of each step otherwise we will get trouble with many events handling. Obviously, each step has some behaviors  such as "next", "back" and "switch' are the same and they are related to each other; but the business of these behaviors can be different totally. That is where the pattern "Chain of Responsibility" can be applied. Step by Step Building It! In this simple pr...

How did I start practising BDD?

In the beginning days, I have practiced TDD (Test Driven Development) using JUnit, I approached that I should test methods belong to a class. For example: I have a class with some methods: public class A{ public void method1(){ } public void method2(){ } } And then, I wrote some test methods to check the corresponding ones, for example: public class ATest{ @Test public void testMethod1(){ .... assertTrue(...); ..... assertEquals(...); } @Test public void testMethod2(){ } } After that, I know that a test method (ex: testMethod1) should just only test one thing, so I decided to write more methods for each case. It looks like the following: @Test public void testMethod1_When_Case1(){ .... assertTrue(...); } @Test public void testMethod1_When_Case2(){ .... assertEquals(...); } However, it was not a really good approach because it seems that I just focused on test the functionality of the method of the class. With the TDD approach, I knew that I s...

Selenium - Use Explicit Waits for checking elements quickly disappear like loading icon

I have a table that is displayed a list of competence groups. When I click on a competence group, it will display a table that contains a lot of criteria belong to the competence group. Each times I click on a competence group, a "loading" icon is displayed while waiting for all criteria is fully displayed. <div id="loading" style="display: none;"> <div></div> <div></div> I tried to write a Selenium test to make sure this behavior is covered. I saw that the loading icon element is always available on DOM tree because I just used Jquery to handle its displaying. Beside that, the loading icon is appeared dynamically and quickly disappear afterwards. It is hard to checking the visibility on GUI of loading icon. By normal way that I frequently used, the code looks like: public boolean isLoadingIconDisplayed() { List<WebElement> loadingIcons = driver.findElements(By.id("loading")); if(!loadingIcons.isE...

Junit - Test fails on French or German string assertion

In my previous post about building a regex to check a text without special characters but allow German and French . I met a problem that the unit test works fine on my machine using Eclipse, but it was fail when running on Jenkins' build job. Here is my test: @Test public void shouldAllowFrenchAndGermanCharacters(){ String source = "ÄäÖöÜüß áÁàÀâÂéÉèÈêÊîÎçÇ"; assertFalse(SpecialCharactersUtils.isExistSpecialCharater(source)); } Production code: public static boolean isExistNotAllowedCharacters(String source){ Pattern regex = Pattern.compile("^[a-zA-Z_0-9_ÄäÖöÜüß áÁàÀâÂéÉèÈêÊîÎçÇ]*$"); Matcher matcher = regex.matcher(source); return !matcher.matches(); } The result likes the following: Failed tests: SpecialCharactersUtilsTest.shouldAllowFrenchAndGermanCharacters:32 null A guy from stackoverflow.com says: "This is probably due to the default encoding used for your Java source files. The ö in the string literal in the J...