What is the meaning of driven ? (test-driven , data-driven, event-driven and etc)

Question

I was reading a paper that makes a comparison between ASP.NET Web Forms and ASP.NET MVC. While reading it, such as data-driven, event-driven, test-driven are the terms that I see a lot. So what are they used for? when we can call them for a programming language or framework? What do they need to have?

Answer 1

Your examples are not comparable to each other.

• Test-driven development drives the development process via automated tests. You don't write code until a test case exists for it and is failing. You write the code to make the unit test pass. This drives the development process forward.

• Data-driven applications drive the flow of the application via external data. You don't know what the application will do unless you have an input file to drive it. At some level, a batch script could be seen as data to drive the shell process. This is not the only possible type of example though, because the term "data-driven" is a very loose term.

• Event-driven applications drive the flow of the application via events. A winapi application is an example of an event driven application. The main guts of the application are based on a tight loop that checks for events, and firing off callback functions when events are raised. SAX is also an example of this.

One of your examples drives the development process. The other two drive the application flow. They are not in any way comparable or orthogonal to each other. In fact you could have an application that used all three techniques.

As for "etc", you can't hand-wave. Every example is completely different.

There is a lot of "driving" going on within the development process. In fact you could say that development is a "caffeine-driven" or "profit-driven" process.

Definition of the word Driven

1. Operated, moved, or controlled by a specified person or source of power.
2. Motivated or determined by a specified factor or feeling.

So you can see that "driven" isn't the important part. The important part is what is driving, and what results that has on the final product (speed of delivery, quality, success of the resulting product - many factors).

You'll have to read, research, and probably experience each technique to tell you whether each will be more useful in some situations, or less useful in others.

Answer 2

Replace it with drives and they make sense.

• Data Driven: Data drives the behavior of the application
• Event Driven: Events drive the updating of the graphical UI.
• Test Driven: Testing drives the way I write code.

Examples:

If the primary storage of the application is a database, or there's a rule engine where the rules are expressed as data, you could say the application is data driven.

If the an engine or model set of generic APIs fire events which the graphical interface uses to update the data shown to the user, you could say the application is event driven.

If the way I write code is to write tests first to prove the API works before others consume it, you could say my development is test driven.

Answer 3

In terms of test-driven, -"driven" means we write code specifically so that we see results in . So, if we are test-driven, we write our code specifically to pass the tests, and hope that the test-writers wrote relevant tests, since we do not care if the user likes it; it passed the test.

As for event and data driven, it is self-explanatory: Without data, the program does not work. The more data it is given, the better it works. As for Event-driven, the program does not even run without an event happening and triggering a call to it.

So, to answer your question, "-driven" is simply a colloquialism to refer to code that depends on some entity to be successful, whether it be good tests, lots of data, or an event occurring. It can mean different things in different contexts.

Answer 4

Simply places the emphasis on the motivational characteristics that defines how a solution is found to a problem.

In other words it anchors the point of view from which one creates the system. It should not be interpreted as a mutually exclusive to other points of views, unless that is, one gets religious about it. Rather it defines very quickly to other peer programmers what hat to put on when looking at the system to gain a faster understanding of it.

Sadly, as all other efficient means of communications it is often abused and misused, one always need to remove any marketing veneer around such definition. Whatever remains will bring you closer to enlightenment.