Trial and error method is the best way of
testing, but repeatedly not fixing of errors would ruin the efforts
taken in testing and is a mere waste of time. Software Testing engineers
while testing make small mistakes unintentionally which seems to be
insignificant but are of high importance.
The following are the mistakes we usually find in software testing:
The First Mistake: Unit Testing is a method by which smallest testable part of an application of source code are tested to determine if they are fit for use. By just calling all utility methods, it's easy to test a utility class, passing some values and examining if the expected result is returned. A first mistake arises here. Majority of the developers don't think out of the box, or not adequate. Developers can test that 1 + 1 =2, that 2 + 1 = 3 and that 3 + 1 = 4. But what is the use of doing nearly 3 times the same test? Testing boundary cases is better. Are the arguments of the sum ( ) method primitive types or Objects? If they are Objects, what happens if you pass null values? If an exception is thrown, is that the expected one? Does it clearly tell what the problem is?
The Second Mistake: Mocks - For example the service layer is unit tested, all other components like the DAO layer should be mocked. Manually in many cases it's been done. That's the second mistake. It's much better to use mocking frameworks because when one mocks stuff manually the mocks are tightly coupled to the implementation as they are made for it. Just believe that they will create the mocks the way they want. Some mocking frameworks are capable of doing more than others; some are easier to use than others. Some of the best mocking framework is Mockito and EasyMock. Mockito is preferred because of its power and simplicity and EasyMock is by far the best known but it's a bit complex too to use. So it's not only a matter of choosing a mocking framework. It's also a matter of choosing the right one.
The Third Mistake: Integration Tests are the tests over different integrated parts of an application while unit tests only tests a LUW (logical unit of work). In integration tests - the best known type of are tests of the DAO layer. In these tests, multiple things are validated: The input parameters, The use of the ORM tool The correctness of the generated query (functional) If the DB can be accessed The fact that the query is working and The fact that the correct ResultSet is returned. The third mistake that is made often is that in the dbUnit XML dataset developers provide test data. Most of the time this data has no representation of live data; the best way to handle this is to make functional-providing people and maintaining this test data. Because one doesn't want to make them struggle with a specific XML format, good practice is to use the XlsDataSet format (Excel Sheet).
The Fourth Mistake: Functional Tests are forgotten too often because the perception is that they are difficult and expensive to maintain. It's true that we'll have to tweak to make them maintainable but executing all the same tests manually over and over again will cost much more. Also when functionality is tested and automated by means of continuous integration, there's no need for stress for screens/ functionality that will be broken in the next release. Selenium is a great framework that is able to record functionality in the browser. The fourth mistake is made here. Most people will just record and replay the tests the way they are. Selenium--HTML components by their HTML id can be tracked. If developers don't specify id's in their HTML code, they can easily change if a page is updated. This will break the tests immediately even when functionality still works.
The Fifth Mistake: This mistake is made in a JUnit test by just pasting the recorded test. Login and logout are common functionalities, the time to wait for a response, should be added to a superior level. For example, a login can be done before each test, afterwards a logout is done. This way, if something changes in login or logout functionality, tests won't break.
The Sixth Mistake: Absence of testing logical flows sixth mistake happens. It's perfectly possible that an insert, a search, an update, and a delete work on their own but that the complete flow from the creation, search, and update until delete of the same entry won't work. The great way to group multiple tests and run them in sequence all together is by the TestSuites.
The Seventh Mistake: BDD (Behavior Driven Design) Instead of functional tests most of the tests are technical tests. To test logical behavior than to test if the things work technically is much more important. That can be done by means of Behavior Driven Design. Given some things, when an event occurs, then what should be the outcome? Mockito has some great stuff to easily write tests in a BDD way.
The following are the mistakes we usually find in software testing:
The First Mistake: Unit Testing is a method by which smallest testable part of an application of source code are tested to determine if they are fit for use. By just calling all utility methods, it's easy to test a utility class, passing some values and examining if the expected result is returned. A first mistake arises here. Majority of the developers don't think out of the box, or not adequate. Developers can test that 1 + 1 =2, that 2 + 1 = 3 and that 3 + 1 = 4. But what is the use of doing nearly 3 times the same test? Testing boundary cases is better. Are the arguments of the sum ( ) method primitive types or Objects? If they are Objects, what happens if you pass null values? If an exception is thrown, is that the expected one? Does it clearly tell what the problem is?
The Second Mistake: Mocks - For example the service layer is unit tested, all other components like the DAO layer should be mocked. Manually in many cases it's been done. That's the second mistake. It's much better to use mocking frameworks because when one mocks stuff manually the mocks are tightly coupled to the implementation as they are made for it. Just believe that they will create the mocks the way they want. Some mocking frameworks are capable of doing more than others; some are easier to use than others. Some of the best mocking framework is Mockito and EasyMock. Mockito is preferred because of its power and simplicity and EasyMock is by far the best known but it's a bit complex too to use. So it's not only a matter of choosing a mocking framework. It's also a matter of choosing the right one.
The Third Mistake: Integration Tests are the tests over different integrated parts of an application while unit tests only tests a LUW (logical unit of work). In integration tests - the best known type of are tests of the DAO layer. In these tests, multiple things are validated: The input parameters, The use of the ORM tool The correctness of the generated query (functional) If the DB can be accessed The fact that the query is working and The fact that the correct ResultSet is returned. The third mistake that is made often is that in the dbUnit XML dataset developers provide test data. Most of the time this data has no representation of live data; the best way to handle this is to make functional-providing people and maintaining this test data. Because one doesn't want to make them struggle with a specific XML format, good practice is to use the XlsDataSet format (Excel Sheet).
The Fourth Mistake: Functional Tests are forgotten too often because the perception is that they are difficult and expensive to maintain. It's true that we'll have to tweak to make them maintainable but executing all the same tests manually over and over again will cost much more. Also when functionality is tested and automated by means of continuous integration, there's no need for stress for screens/ functionality that will be broken in the next release. Selenium is a great framework that is able to record functionality in the browser. The fourth mistake is made here. Most people will just record and replay the tests the way they are. Selenium--HTML components by their HTML id can be tracked. If developers don't specify id's in their HTML code, they can easily change if a page is updated. This will break the tests immediately even when functionality still works.
The Fifth Mistake: This mistake is made in a JUnit test by just pasting the recorded test. Login and logout are common functionalities, the time to wait for a response, should be added to a superior level. For example, a login can be done before each test, afterwards a logout is done. This way, if something changes in login or logout functionality, tests won't break.
The Sixth Mistake: Absence of testing logical flows sixth mistake happens. It's perfectly possible that an insert, a search, an update, and a delete work on their own but that the complete flow from the creation, search, and update until delete of the same entry won't work. The great way to group multiple tests and run them in sequence all together is by the TestSuites.
The Seventh Mistake: BDD (Behavior Driven Design) Instead of functional tests most of the tests are technical tests. To test logical behavior than to test if the things work technically is much more important. That can be done by means of Behavior Driven Design. Given some things, when an event occurs, then what should be the outcome? Mockito has some great stuff to easily write tests in a BDD way.
