1

I’m curious to know how feasible it is to get away from the dependency onto the application’s internal structure when you create an automated test case. Or you may need to rewrite the test case when a developer modifies a part of the code for a bug fix, etc. We could write several automated test cases based on the applications internal object structure, but lets assume that the object hierarchy changes after 6 months or so, how do we approach these kind of issues?

Venkat Raman
  • 103
  • 14
  • possible duplicate of [Should one test internal implementation, or only test public behaviour?](http://stackoverflow.com/questions/856115/should-one-test-internal-implementation-or-only-test-public-behaviour) – DBedrenko May 18 '14 at 13:47
  • Sorry, I do not see my answer in the link posted. I am trying to understand as to how we need to approach such problems. Any pointers? – Venkat Raman May 18 '14 at 13:50
  • If you test your program through the public interface, then the unit tests don't need to be changed when implementation details change. – DBedrenko May 18 '14 at 13:53
  • To be clear I do not perform unit tests. I perform functional automated tests using tools like TestComplete or QTP. – Venkat Raman May 18 '14 at 13:54

3 Answers3

1

I can't speak for other testing tools but at least in QTP's case the testing tool introduces a level of abstraction over the application so that non-functional changes in the application often (but not always) have no effect on the way the testing tool identifies the object.

For example in QTP all web elements are considered to be direct children of the document so that changes in the DOM (such as additional tables) don't change the object's description.

Motti
  • 110,860
  • 49
  • 189
  • 262
  • True, They are children of a document. What about windows based applications. A button could be nested several layers beneath its corresponding main parent. This is the case in some complicated C# WPF kind of applications. – Venkat Raman May 19 '14 at 04:41
1

In TestComplete, there are a couple of ways to make sure that the changed app structure does not break you tests.

  1. You can set up the Aliases tree of the Name Mapping feature. In this case, if the app structure is changed, you need to modify the Aliases tree appropriately and your test will stay working without requirement to modify them.

  2. You can use the Extended Find feature of the Name Mapping in order to ignore parts of the the actual object tree and search for a needed objects on deeper levels.

Dmitry Nikolaev
  • 3,803
  • 2
  • 19
  • 23
  • Agreed! Any other approaches we can use? we could perform a find, findall, findallchildren operation to locate a child. Regular expressions or wild card matching should help us at some point. But by then our tests written would have failed already. Is it a routine for an automation engineer to keep re writing test cases whenever there is a change in object tree? – Venkat Raman May 19 '14 at 07:37
  • Yes, keeping the object mapping scheme updated is a usual task for a QA engineer. As for the Find methods, you can use them indeed. However, the Name Mapping feature provides the same functionality in a more convenient way. The most serious problem is that it is not easy for a new users to understand how to use this powerful feature. – Dmitry Nikolaev May 21 '14 at 04:42
1

This is what I was forced to do after losing all my work twice due to changes on the DOM structure:

Every single time I need to work with an object, I use the Find function with the ID of the object, searching for the object on the Page object. This way, whenever the DOM gets updated, my tests still run smoothly. The only thing that will break my tests is if the object's ID get changed, but that's not very probable to happen.

Here you can find some examples of the helper functions I use.

Gabriel Pita
  • 336
  • 1
  • 3
  • 13