Why DTF

When compared to other testing tools/frameworks DTF has been designed to solve a few problems that others have yet to try to solve. The XML language in DTF has quite a few features that become evident as you start to use DTF regularly, so I'll try to explain some of these benefits in a few bullet points that compare DTF's XML Language to a more common scripting language (python, ruby, perl, etc) used for writing tests.

• Scripts become out dated between releases frequently and when there are changes made to the application usually this leads to have to make independent changes on each of the many tests written for a given release. DTF solves this with its XML language, that can easily be transformed using a style sheet (XSL). This means you can create a new set of tests or even add logic to your existing tests to handle any new situations for the new release API. Aside from the fact that this saves you many man hours it also saves you from copy and paste errors, when making manual changes to hundreds of test files in order to adapt tests between releases. See the following example on how to use XSL to adapt your tests easily.

• Scripts are hard to read since most scripting languages are very extensive and allow the same thing to be done in N different ways. This doesn't mean that DTF's XML language makes it hard for you to write things. The language itself has been designed to allow you to do extremely complex things with very simple group of tags and make it always easy to easily understand what a group of tags is doing. The main reason its easier to read is because of the way XML nesting makes it easy to understand what each block is doing.

• Documentation for scripting languages gets out of sync easily when there are multiple people making changes to the same APIs. This is due mainly to the fact that code and documentation for code rarely reside in the same location. This has been solved in DTF by having the documentation for each tag present in same Java class that contains your tags code. Using JavaDoc comments right in the middle of the code, you are able to add examples, descriptions and format this in HTML. The only reason for not updating the documentation is laziness.

• Scripts aren't easily ported between environments because they allow the end user to refer to paths in the system and/or other environment specific elements that then will block you when trying to run the same tests on completely different environment. DTF has solved this by never allowing you to reference the file system directly except through the use of storages which abstract the location of those files within the test. The other thing DTF does to help changing environments is that each tag can easily be implemented to detect the environment and change its behavior slightly so that the tests suffer no changes and yet the tests execute appropriately within each new environment.

• No scripting languages ever make it easy to spawn multiple threads and be able to synchronize them without having to really know what you're doing in terms of using mutexes and POSIX threads and basically being a developer of some code that is prone to the usual bucket of synchronization bugs. DTF has solved this problem with the existence of very simple tags that allow you to define concurrency and to be able to synchronize your events between threads not just on the same machine but over the network on a completely different host. This allows you to write tests in a few hours that would take you a few days to code in any other scripting/programming language because you'd have to deal with everything from threading, concurrent access to shared resources and network communication between those hosts.