Some tools that can be used in Test Driven development

Here we present a list of tools that can be used for carrying out Test Driven Development (TDD). The test driven development is equivalent to the Big upfront designing. The efficiency and the development speed both are improved in this process. Finding mistakes is quite fast and cheap in TDD. The iterations are short and therefore provide a means for frequent feedback. The test suites are up to date and executable and serve as a complete documentation in every sense. The tests are written before the code. Then the code is refactored to produce high quality code.

Tools for TDD are:
• JUnit: this is the java’s unit – testing framework.
• Some commonly used refactoring tools are RefactorIT, IntelliJ IDEA, Eclipse, Emacs and so on.
• HTTPUnit: This is a black box web testing tool and is used for automated web site testing.
• Latka: A java implemented functional testing tool. This tool can be used with JUnit or Tomcat.
• Cactus: A server – side unit testing tool provides a simple framework for unit testing on server side. It also extends on JUnit. The tool provides three types of unit tests i.e., the code logic unit testing, functional unit testing and the integration unit testing.
• Abbot and Jemmy: Tools for GUI testing. The first one keeps a scripted control on actions based on high level semantics. Jemmy is more powerful and provides full support for swing.
• Xmlunit: This tool lets you draw comparisons between 2 xml files.
• Ant: The tool is based up on java and xml. It is completely platform independent.
• Anteater: An Ant based testing framework. It is used for writing tests that check the functionality of web services and web applications.
• Subversion: This one is a replacement for CVS and controls directories in a better way.
• Jmock: The tool uses mock objects that are dummy implementations of the real functionality and are used for checking the behaviour of the code. The non – trivial code cannot be tested in isolation. Unit tests can be used for everything right from simplification of test structure and cleaning up domain code. You should start from testing one feature at a time and rooting out the problems one by one. Carrying out the testing normally without using any mock objects can be hard. Before carrying out the test, you should decide what needs to be verified. Then you must show that it passes the test. Only after this, the mock objects can be added for representing these concepts.


• csUnit
• CUnit
• Googletest
• DUnit
• HTMLUnit
• NUnit
• OUnit
• PHPUnit
• pyUnit

The above mentioned tools are used for writing unit tests in Test Driven development. However, these unit tests are bound to have errors. Also the unit tests are not apt for finding errors resulting because of interactions between different units. The path to success involves keeping things as simple as possible.
The end result of TDD is highly rewarding. The program design is organic and consists of loosely coupled components. All that you think can go wrong should be tested by proceeding in baby steps. One thing to be taken care of is that the unit tests should run at their 100%. Refactoring is not about changing the behaviour of the code. It is about making improvements to the internal code structure. It should be carried out to improve the quality, maintainability and reliability of the code.

What is the difference between Test Driven development and Acceptance Test Driven development?

Test driven development (TDD) and Acceptance Test Driven Development (ATDD) are related to each other. TDD is a developer’s best tool for helping in creating properly written code units i.e., modules, classes and functions, that carry out the desired function properly. On the other side, ATDD acts as a tool for communication between the developers, testers and the customers to define requirements. Another difference between TDD and ATDD is that the former requires test automation while ATDD does not. But ATDD might require automated regression testing. The tests written for ATDD can be used for deriving tests for TDD. This is so because a part of the requirement is implemented in the code. It is important that the tests must be readable by the customers, but it is not required for TDD tests.
TDD involves writing the test cases and making them fail before the code is written. Next enough code is written to make the tests pass and then refactor it as per the requirements. The tests must pass after it. The primary focus of TDD is on methods and single classes i.e., the low level functionality. This leads to much flexible code. Now what is the need for ATDD? The reason is that the TDD just tells you that your code is fine but it doesn’t tell you why that piece of code is even required. However, in ATDD, in the early stages of the software development process itself the acceptance criteria are stated. In the succeeding stages of development process this criteria is used for guiding the development. ATDD is more like a collaborative activity engaging everyone from developers and testers to business analysts and product owners. It ensures the implementation process is understood by everyone involved in the development process.
There is a third thing called the BDD or the behaviour driven development. This one is quite similar to TDD except that we call tests as specs. The focus of the BDD is on system’s behaviour rather than its implementation details. It also focuses on the interactions taking place in software development. Developers following this approach make use of two languages i.e., the domain language and their native language. TDD consists of unit tests while ATDD uses acceptance tests. Plus, the focus is on high level. BDD is required for making the product more focussed on customer. BDD allows the collaboration of developers with other stakeholders easy. Using TDD techniques and tools requires technical skills because you have to know the details of the object. Non – technical stakeholders would be lost while following the unit tests of TDD. BDD provides a clearer view of the purpose of the system. TDD provides this view to the developers.
The result of the methodology of ATDD is entirely based up on the communication that takes place between the developers, testers and their customers. A number of practices are involved in ATDD such as Behavior driven testing, specification by example, story test – driven development, example – driven development and so on. With these processes, the developers are able to understand the needs of the customers before the actual implementation. The difference between TDD and ATDD arises because of the latter’s emphasis on the collaboration between the three i.e., developers, testers and customers. The acceptance testing is encompassed in ATDD but in one way it is similar to TDD i.e., it insists on writing the tests before coding can be started. These tests provide an external view of the system from the point of view of a user.

What are some of the problems of Test Driven development?

The Test driven development (TDD) does have a lot of benefits, but you would expect some issues, and there are some problems too. Regression testing, though sufficient and good enough for most cases of software development, there are sometimes situations where testing requires full functional testing. In these situations, partial functional testing cannot be used for determining success or failure since a large number of unit tests are used. The types of software facing this problem includes user interfaces, programs using databases and certain network configurations. This is so because of the feature that is typically an advantage of TDD, is a disadvantage too in this situation. This feature is that TDD encourages programmers to write modules with minimum amount of code with maximum logic that can be tested using mock – ups and fakes. The outside world of the module is also represented using these mock – ups. Another shortcoming of TDD is that it cannot do without management support. It is essential for its efficient existence. If the entire organization does not believes that TDD will improve their product, it may seem to management that it is wasting time in writing the tests. Also in TDD, the programmer who is writing the code is responsible for writing the units tests which means – a number of blind spots in the code will go untested. It is always a good practice to have unit tests written by someone else. Certain things to be checked might not come to the notice of the developer leaving the code partially tested.
Take another example where the requirements of a module are misinterpreted by the developer. In this case both the code as well as the unit tests that he will write will be wrong. So the even though incorrect, the tests will pass and the developer will assume that his code is correct. Also if these unit tests are many in number, they will pass giving a wrong sense of security which might result in less testing of the software i.e., compliance testing, integration testing etc. writing and executing tests adds to the maintenance overhead of the software. Tests with bad code such as error strings or code which is prone to failure are quite expensive when it comes to maintenance.
The same is the case of fragile tests. They involve risk that tests likely to generate failures regularly will be neglected. Therefore, when a failure occurs in actual, it won’t be detected. Though a bit difficult, it is possible to write code that requires low maintenance. This can be done by reusing the error strings wherever possible. Code refactoring should focus on code reusability. Writing and executing a lot of tests takes a lot of time too. However, some flexible modules having few tests might incorporate new requirements without having to make any changes in the tests. It is because of this reason that it is easy to adjust with few number of tests and little data than with big and complex tests. With advanced factor analysis and sampling skills, developers can be warned of excessive – testing.
The repeated TDD cycles achieve a level of testing and coverage that cannot be recreated later. Therefore, this original coverage is very much essential and has to be fixed early. On the other hand if the testing strategy is poor, changes must be fixed individually. And this should be done carefully as just deleting or disabling them can cause holes in the coverage. TDD insists on writing tests for every part of your code which instead of making it better, might make it contorted and damage it. 

How does Test Driven development benefit developers?

Test driven development (TDD) as a process has proven to be a boon for developers time and again. Businesses tend to change rapidly with the time and so does their requirements from the software that they are using. If we develop these software products using the traditional development methodologies, it is obvious that later it will be more difficult for us to maintain them as requirement changes. If you suggest making changes to the existing model developed using traditional method, it might create havoc in unpredictable ways. As a result of these consequences, organizations often don’t go for modification of the existing software as it might hamper their productivity and effectiveness. But this is no problem for companies who have developed their products using TDD. This is so because it is like a continuous integration model in which testing modules are added. Then it becomes easy for the organizations to make modifications to their products, without fearing any breakdown.

First benefit of TDD to developers is that it is easy for them to maintain the software by virtue of its extensibility and flexibility. Since both testing and development go hand in hand in TDD at the lowest level, it guarantees testing of every single logical piece and can even be changed. Once the development is done, the application is tested once again with thousands of tests. After making a change to the application, associated tests are run to see if there is any impact on the other parts of the application. With this approach there occurs no problem in modifying the existing legacy applications. Apart from benefiting developers, this has benefits for organizations seeking growth by making it easier for them to update their systems.

The codebase is streamlined along with test coverage which is unparallel. In TDD, writing a test first before writing code is mandatory. That is how it provides unparalleled coverage. Further, regression testing and refactoring make the code as minimal and economical as possible. This plays a big role in streamlining the codebase. If for a functionality there is no use case, the test is not written and no code and thus there is no growth in the codebase. This is also another reason behind easy maintenance.

TDD provides a clean interface throughout the development process. Since the tests are written first, the APIs thus produced are from the perspective of an API – user. That’s why it is very easy to use these APIs when compared to the APIs written by programmer’s perspective.

The code refactoring process is central to the success of TDD and makes sure that the codebase is strengthened preventing the software from getting outdated and monolithic.

TDD aims at improving the code and is particularly useful in the following:

> Addition of new feature or functionality: With TDD the programmer feels confident in changing part of a large application (even otherwise the programmer might feel confident but this feeling may not be shared by other stakeholders). If it wasn’t flexible, then we would be adding functionality to the application but without any proper integration. This would have definitely caused many problems.

> Changes in the technical infrastructure: Developers are always thinking of making technical changes to the code for increasing its elegance and make it more extensible.

The use cases used in TDD are actually tests which can be used by the other developers as examples of how the code works and how it can be used. Thus TDD provides executable documentation. Updating the software without any painstaking efforts has been possible because of TDD.

An organization can be successful only if it embraces the changes and makes improvements. Test driven development makes all this possible with its extensability, maintainability and flexibility. 

Test Driven Development - Some benefits

According to a study, test driven development involves writing more tests and thus makes programmers more productive. The hypotheses produced from the study were inconclusive regarding code quality and relation between productivity and TDD. Programmers that use the pure test driven development on projects said that they rarely felt like invoking the debugger. Version control system and TDD when used together, makes it easy to revert the code when it fails unexpectedly to the previous form that passed all the tests. Thus debugging here proves to be less productive than reverting.
TDD has more to offer other than just correctness validation. It can also be used for driving the designing process. Since the focus is shifted to the test cases, the programmer can see how the client will be using the functionality. As a result of this programmer’s concern with interface increases. This benefit of TDD is just the opposite of design by contract. It is so because we approach through test cases rather than using preconceptions and mathematical assertions.
With TDD you get the ability to proceed with programming in small steps with as much as you are comfortable with. Thus you are able to concentrate at the present task where your goal is to make the code pass the test. Initially in TDD, we are concerned with error and exception handling. There is a separate process for creation and implementation of these extraneous situations. This way it is ensured that at least one test covers each part of the code. The programmer’s and users’ confidence in the software is boosted.
Even though it is obvious that programming with TDD requires more code than with other techniques, according to a model by Müller and Padberg, implementation time in TDD is shorter. The defects are caught early because of the frequent testing in the development cycle. The errors are thus prevented from turning into expensive and endemic bugs. It also reduces the time period of debugging phase. The code produced with test driven development is more extensible, flexible and modular. This is by virtue of TDD’s methodology of forcing the programmers think in the terms of smaller code units. The benefit of all this is that you  get a cleaner, focused but loosely coupled code.
The modularization of the code to some extent is also affected by the design pattern of the mock objects used. This is so because the pattern requires writing the modules so as to make it easy to switch between versions for deployment and testing reasons. Every code path is covered by the automated tests unless no more code is required for the code to pass the test. For example, if the programmer wants to add an else branch to an if statement, then his first requirement is to write a code that causes that branching. That is why all the tests produced in TDD are quite thorough and even the most unexpected of the changes is detected.
It has been proved experimentally that TDD approach is superior to the tradition test – last approach when it comes to lower CBO (coupling between objects). The experiment also showed that TDD results in better modularization, easier testing and reuse of the already developed products. The effect of the TDD approach on generation of unit tests was measured using the MSI (mutation score indicator) and the BC (branch coverage). These indicate the effectiveness and thoroughness of the unit tests. A medium effect is represented by a mean effect size based up on the meta – analysis of the experiment that was performed. For branch coverage the effect size was medium and therefore taken to be substantive. 

Test Driven Development - The Process

Continuing from the previous post on the basics of TDD (link), this post continues with the topic of Test Driven Development.

What is the process of Test Driven development?
For the test driven development to be implemented on some software artifact, its units should be kept small. By units here we mean a group or class of functions related to each other. Sometimes these units might also be referred to as the modules. These are a couple of the benefits of using small units:
> The debugging effort is reduced – Upon detection of test failures; it becomes easy to track down the faults when you have smaller units.
> Tests are often self – documenting: Readability and understandability is increased by virtue of small tests.

TDD can be converted into ATDD (acceptance test driven development) by mixing TDD with more advanced practices. The criteria that the customer specifies are converted into acceptance tests which are then used for driving the UTDD (unit TDD) process in traditional manner. With this process it is ensured that there is an automated mechanism which can be used by the customers for deciding whether their requirements have been met or not. The ATDD provides the development team with a fixed target i.e., the acceptance tests which keeps them steadily focused on the requirements of the customers. Now let us examine the TDD cycle. It's test driven development cycle consists of the following phases:

1. Adding a test: The beginning of a new feature is marked by writing a test which must fail because of being written before the implementation of the feature. If this test succeeds then either the test is defective or the feature has already been added to the software. Before writing a test, the requirements and specifications must be fully understood by the developer by means of user stories and use case stories. This step puts the focus of the developer on the requirements before he/ she begins writing the code that makes a subtle yet importance difference.
2. Running the tests and checking if they fail: This step does the step of validating the correct working of the test harness. The test itself is also tested in this process ruling out the possibility that the new test will pass always. This results in increase in confidence in software.
3. Allowing the test to pass by writing some code: the code written at this step is not perfect as proved by later tests but it is eventually improved. The code is written only to pass the test.
4. Running the tests: If all the tests pass, the programmer can be sure of the code that the requirements are being met.
5. Refactoring the code: Now the code has to be refactored as required. This also involves placing the code in its logical place and removing any redundant code. It has to be made sure that the function and variable names represent properly their current values. Any misinterpreted constructs should be clarified. After this the code should be re – run to be sure that the refactored code has not changed the other functionalities.
6. Repeat: Another test is taken to test the next functionality. The steps should be kept small. If the new code does not satisfy this test or if it fails, the changes made should be undone instead of excessive debugging. Maintaining revertible checkpoints becomes easy if continuous integration is used. If external libraries are being used, then it is necessary that the size of the increments should be as small as the library itself unless the library is not sufficient or it has bugs. Between each test run, there can be maximum 10 edits. This cycle goes on until all the functionalities have been tested.

What is Test Driven development?

The test driven development (or TDD in short) is a type of software development process that emphasizes on the use of repetitive development cycles. These development cycles are quite short when compared to the cycles followed in other development processes. Initially an automated test case i.e., an initially failing one is written by the developer defining a new function or improvement that is required. Next a code is produced (as small and as efficient as possible) for passing the test. Lastly, this code refactored so as to make it standard compliant. This technique was discovered by Kent Beck in the year of 2003. He stated that this software development technique is an inspiration for confidence and produces simple designs.
There is a similarity between extreme programming’s concepts of test – first programming and this test – driven development process. However, lately TDD has developed a general interest for its own. The concept behind the test driven development is also applied to the debugging and improvement of the legacy code that has been produced using some older methods. There are a number of aspects in which test – driven development can be used. For instance, TDD principles such as YAGNI (you aren’t gonna need it) and KISS (keep it simple stupid) are used in general context too. Since the focus is on producing only the required amount of code necessary to pass the test, the code that is developed is much clear and clean than what is developed by other methods. Another famous principle of TDD is “fake it till you make it”. For achieving some concepts including advanced design (for example, design pattern), the tests that would produce this design have to be written. The code may be simpler than the actual target code but would still pass all the tests.  At first, you might seem to disagree with it but, on the positive side it allows the developer to focus on the important things.

The first thing that should be done is to write the tests even before the functionality that has to be tested. This approach has a number of benefits:
- It helps in ensuring that the application is test ready making it easy on the developers on how to test it from outset. It eliminates the scene of worrying later.
- It makes sure that for every feature there is a test.
- This approach facilitates an early understanding of the product requirements. Thus, ensuring the test code’s effectiveness. Also the product quality can be focused up on continually.

On the other hand, the feature – first code pattern in development organizations may push the developer to the next feature which results in negligence in full testing. Also the compilation for the first test might not even take place because the classes and functions it requires might not exist then. But, even then the first tests are treated as executable specifications.
The test cases are first failed for ensuring that the test is working and is able to catch the fault or error. Once this is established, we can proceed with the implementation of the underlying functionality. This strategy is called the “test driven development mantra”. Also known as the red/green refactor where red stands for failing and green stands for passing. In TDD we repeat the process of adding the failing test cases and then passing them and again refactoring. When at each stage the programmer receives the expected results, his mental code model keeps getting stronger and reinforced. Further this boosts his productivity and instills in him a sense of self - confidence. This is the development style that TDD follows.

What is meant by Behavior Driven Development (BDD)?

BDD or Behavior Driven Development is one of the most important development approaches in the field of software engineering and is just a modified implementation of the TDD or test driven development. It actually combines the guiding principles and general techniques of the test driven development with the combined ideas from two sources namely:

1. Domain – driven design
2. Object – oriented analysis and design

- The behavior driven development thus provides a shared process and tools to business analysts and software developers for their collaboration on the software development process.

- Ideally, behavior driven development represents an idea regarding the management of the software development process by both technical sight and business interests.

- It is assumed in this approach that the specialized software tools are being used to provide support to the development process. 

- The specialized tools thus involved have been developed especially to be used in projects following the BDD approach. 

- They can be considered as special tools that supports test driven development. 

- The primary purpose of these tools is to automate the ubiquitous language statements around which the BDD process is centralized. 

- Agile software development gets successful only when it is considered from the beginning. 

- On the contrast, in some projects this is the last thing to be considered which means that there is no sustainable operation in the websites that serve purposes other than blogging.

-  A blogging web site is just a software that is just modified by the users as it is ready for use. 

- However, BDD and TDD provides the only ways for achieving this goal. 

- The word ‘driven’ in TDD signifies that the test cases are written first and then the code for passing the test. 

- TDD is actually a low level methodology of accomplishing tasks and is sort of developer oriented. 

- On the other hand in BDD, the description of the tests is written in a natural language, thus making the tests more accessible to people outside the development team. 

- Such descriptions can describe the functionality in the same way as done by the specifications. 

Dan North was the person who actually brought the concept of behavior driven development in response to the issues experienced in implementing the test driven development such as:

1. From where to start testing?
2. What is to be tested?
3. How much should be tested in one turn?
4. How the reason for the failure of the test is to be understood?

- At the heart of the behavior driven development approach lies the approach to acceptance testing and unit testing which were again identified by North. 

- He emphasized that the acceptance tests should be written using the user story frame work. 

- Thus starting from the scratch, the development of the BDD approach continued over a couple of years and finally we have it as a communication and collaboration framework. 

- It has been designed especially for the QA people and business participants involved in a project.

- The agile specifications, BDD and testing eXchange meet highlighted the following characteristics of BDD:

1. Second generation methodology
2. Outside – in approach
3. Pull based
4. Multiple stake holder support
5. Multiple scale generation
6. High automation process
7. Agile methodology

- Further, it was said that it involves a cycle of interactions with outputs that are well defined and results in delivery of working software that makes sense. - First, BDD frame work that came in to existence was Jbehave which was followed by Rbehave–a story level BDD ruby frame work.

- All these frameworks were later replaced by cucumber testing tool. It was developed by Aslak Hellesoy. 

What are common mistakes and misunderstandings in a unified process?

As it is always said “to err is human”, one may make innumerable mistakes. This truth holds good for every aspect of our lives and so for the technology also. While programming, it is obvious that some mistakes will be made but they are not intended, some mistakes might creep in without the knowledge of the programmer; other mistakes might arise due to a lack of knowledge of the programmers and the developers! 

Anything is possible. With so much complex and advanced software systems and applications to build around it is obvious for the programmers and the developers to make mistakes while programming the software because it is not the feature of human intelligence to keep of check of each and every bit of the program that is being built.

Well, this article has been focused up on the mistakes and misunderstandings that result in mistakes in a unified process. Such mistakes and misunderstandings in a development can cause severe problems in the whole development process causing further problems in the software system or application that is being built. 

What are common mistakes in unified process?

There are various mistakes that one can make while programming using the unified process. 

- The very common mistake that is done is that the complex problems might be made more complex due to lack of sufficient understanding of the methodologies that are available for programming or may be because wrong or inappropriate methodologies might have been put in to use. 

- The problem that occurs here is for adopting any software development process different people assume different values and hence it is like using a single software development process for every programmer or developer.

- For getting the appropriate solutions to the programming problems it is not necessary that the programs should be developed with the extreme agile or test driven development methodologies. See this is where the people make mistakes!

- When a software system or application can be developed using the simplest of the methodologies available then why go for the complex and the tough ones? 

- Even though the agile processes and the unified software development processes are a big step towards the advancement of the software development, it is not always that they can be extended for all sorts of softwares and applications.

- The best way to avoid much of the problems is to train the programmers and developers in information protection. It does not require months and weeks to learn about common software security mistakes and misunderstandings. 

Examples of Common Mistakes

- Suppose that during programming a file was not locked properly and there are two parts of the programs that access the same file without properly locking it. 

- Such a case can result in a race condition between the two programs that can make the file quite unstable or in a vulnerable condition. 

- Another mistake can be logging in trying many passwords in just few seconds without giving the system a proper time to check. 

- The spirit of a programmer should be as such that even if he/ she has not made the mistakes he/she should take the responsibility to correct them before they cause more harm to the software system or application. 

- The longer the time is spent on writing the programs the more you avoid the mistakes. 

What is the use of a mock object in test driven development?

Over the years the idea of the mock object was materialized and today they are being used in numerous testing and development methodologies. Nowadays mock objects find their use in many testing methodologies like the unit testing and also in development processes such as the test driven development process. 

This article is focused up on the use of a mock object in the test driven development process. But, before moving further we shall give a brief discussion regarding the concepts of the mock object so that understanding the use of mock object in the test driven development becomes easy for you. 

Mock objects are known as the fake objects that in a way simulate the behaviour of an original or to say a non mock object whenever any of the following conditions are prevalent:

     

     1. If the non mock supplies non deterministic output.

     2. If the non mock object is difficult to be reproduced or recreated.

     3. If the non mock object is quite slow i.e., is using a complete data base.

     4. If the non mock object tends to change its behaviour.

     5. If the non mock object does not yet exists.

     6. If the non mock object demands information and methods exclusive to the testing purposes.

   

What are Mock Objects?

- Mock objects are nothing but fake objects but with a little more purpose of testing the other non mock objects with the method implementations having assertions of their own. 

- They are employed for the examination and verification of the context of each and every method call.

- Apart from this, they are also used to determine the order in which the methods are called and implemented using data that was passed as the arguments in the method calls.

- Mock settings are an effective means for ensuring that an exception is generated by the software system or application when the subsequent calls to it are made like it may hang, fail or crash etc. 

- With the mock settings, it has become possible to test the client behaviors against all the realistic faulty conditions as well as they can be developed also in the back end sub systems. 

- Without the use of mock objects it will be too difficult to test these conditions. 

- The mock system provides a simple and flexible way to test the realistic fault conditions since proper consideration is given to them.

- With the mock methods it has become easy to add entries to a public log string. 

Use of Mock Object in TDD

Now coming to the use of mock objects in the test driven development, mock objects are used in 

the test driven development during the writing of the software. 

- With the help of mock objects the programmers and developers are able to write and unit test functionality in a defined area by using the mock objects that provide all the interface requirements of the complex real objects rather than using the complex collaborating and underlying classes and objects. 

- With the help of mock objects the programmers are able to focus properly on the testing of the behavior of the SUT or system under test. 

- They don’t have worry about the objects on which it is dependent. 

- There are some practical speed issues also involved with the use of mock objects in the test driven development apart from the complexity issues.

- To develop a realistic piece of software employing the test driven development may require hundreds of unit tests. 

- If any communication is developed between these unit tests and the data bases, networked systems and web services, then it is possible that the suite of unit tests will become quite slow. 

Compare Test Driven Development (TDD) and Agile Model Driven Development (AMDD)?

The test driven development and the agile version of the model driven development i.e.., the agile model driven development are now much in the talks these days!! But many people get confused between the two and are not able to distinguish between them. 

This article is all about a comparison between the test driven development (TDD) and the agile model driven development (AMDD).  

"Agile model driven development involves the creation of the agile models rather than extensive models as in the case of MDD and the whole development process is driven by these models only." 

"The test driven development is not an agile method but the AMDD is and it is used for scaling the agile software development."

Stages of AMDD

 The following are the stages of the high level life cycle of the AMDD:

1. Envisioning
2. Iteration modelling
3. Model storming
4. Reviews
5. Implementation

Stages of TDD

 Below mentioned are the steps that form the short development cycles in a test driven development process:

1. Addition of a test
2. Execution of all tests in order to check the working of the new one and also for the validation of the test harness for its correct working. 
3. Execution of the automated tests and observing their success.
4. Re-factoring of code and cleaning up of the code.
5. Repetition of the whole cycle in order to improve the functionalities.

One of the common scenes during the development is of the model storming sessions. All of the team members model storm for few minutes and then get back to the coding work. The coding is done using many agile software development practices like:

1. Refactoring
2. Test first designing (TFD)

- The above two processes consume time depending up on the complexity and length of the code.

- It may take several hours to implement what has been modelled in the model storming session. 

- The test driven development is actually being implemented here since the combination of the above mentioned two processes is nothing but test driven development. 

- This is the stage where the most of the time of the development team will be spent. 

- Since this is a sort of agile software development, most of the modelling is carried out in the form of executable specifications with the help of development or customer tests. 

- All these efforts are supposed to work since with the agile development you are able to think through the cross entity issues and with the test driven development you are able to think about the much focussed issues. But you can take up only a single entity at a time. 

What more? 

- The re-factoring helps you evolve your design in small iterations to maintain the high quality of your work. 

- With the test driven development the confirmatory testing of your program’s code is done and also the detailed specifications are given. 

- The above mentioned customers tests are also the agile acceptance tests and they form a part of the detailed requirements that are tested by the developer as detailed design.

- Such tests serve as a great example of the single sourcing information.

- Single sourcing is nothing but a technique used by the developers to reduce the overall documentation and thus travel light. 

- In the whole process, the high level specifications should not be over looked. 

Explain Agile Model Driven Development (AMDD) lifecycle?

“AMDD” is the abbreviated form of the “agile model driven development” and nowadays is quite popular among the developers and programmers in the field of software engineering and technology.

AMDD took its birth from the “MDD” or the “model driven development” as its agile version that makes use of the agile models rather than using the extensive models in the pure model driven development. 

The agile model driven development was formulated out of model driven development since it was thought that the iterative development with the model driven development is possible. And since it constituted of the iterations, it was categorized under the category of agile software development methodologies. 

The agile models that drive the whole development procedure are good enough to take care of the development efforts. The agile model driven development is one of the most sought after beyond the small agile software scaling development methodologies.

Agile Model Driven Development Lifecycle

To understand this whole agile model driven development one needs to familiarize himself/ herself with the life cycle of this development model. This article is focused up on the life cycle of the agile model driven development only!

The life cycle of the agile model driven development is of quite a high level. So let us see what all are the various stages in the life cycle of the agile model driven development:

1. Envisioning: 

This stage of the life cycle is comprised of two more sub stages namely: the zeroth and the first iteration. These iterations usually come in to play during the first few weeks of the development process. This stage is actually included in to the life cycle with the purpose of the identification of the scope of the system and what kind of architecture will be suitable for developing the project. For this the following two sub stages come in to process:

(a)  Initial requirements envisioning or modeling: 

This stage may take up to several days for the identification of the high level requirements. Apart from just identifying the requirements the scope of the release product is also determined at this stage only. For carrying out with this stage the developer may require some type of usage model in order to see how the software project will be used by the customers or the users.

(b) Initial architecture modeling: 

This stage is all about setting up of a proper technical direction for the development of your software project.

      2. Iteration Modeling: 

     This stage involves planning for what is to be done with the current iteration. Often the modeling techniques are ignored by the developers while planning objectives for the iteration that is to be carried out next. The requirements in every agile model as we know are implemented in the order of their priority.

     

      3. Model Storming: 

      As mentioned in the agile manifesto the development team should consist of only a few members who are the ones who discuss the development issues by sketching it up on a white board or paper. The sessions which involve activities such as those are called the model storming sessions. These sessions are short enough to last for at most half an hour.

   

     4. Test driven development involving the executable specifications: this stage involves the coding phase using the re-factoring and test first design (TFD). The agile development helps you address cross entity issues whereas with the test driven development you can focus up on each and every single entity. Above all the technique of re-factoring the design, it is ensured that the high quality of the software project is not hampered at all.

What are different Myths and Misconceptions surrounding Agile Model Driven Development (AMDD)?

The agile version of the model driven development or AMDD (agile model driven development) is now being recognized one of the most popular development models in the field of software engineering. This agile model driven development methodology was born out of a need of a combined development process of the agile methodology and the test driven development or TDD. 

The agile development in this combination is supposed to make the addressing of the cross entity issues easy while the TDD (test driven development) counterpart is suppose to focus exclusively on each and every individual entity of the software system or application. 

About Agile Model Driven Development

The agile model driven development lately has been known to suffer a lot of criticism giving way to the birth of several myths and misconceptions regarding it.

- The agile model driven development methodology has been characterized as an obsolete agile software development methodology to some extent though not so much. 

- The agile model driven development is thought to involve only a little bit of modeling but quite a lot of coding.

- The iterating efforts are deemed to be spread between the coding activities and the software modeling activities.

- Here a feel like illusion of majority of the designing being carried out as a part of the implementation efforts is created. 

- Such situations are also true for many other traditional software development methodologies. 

- In situations like this what happens is that the designers ultimately put the blame on the developers without questioning their own way of processing the software development.

- One of the misconception regarding the agile model driven development is that it does not specifies what all types of the software models are to be created.

- Even though it is always specified by the agile model driven development that only the right artifact is to be applied, it never does specify what that particular artifact really is. 

- One of the myths is that the agile model driven development works perfectly well with the UCDD (use case driven development) and the FDD (feature driven development). 

Myths and Misconceptions of Agile Model Driven Development

Below mentioned are some of the other myths and misconceptions surrounding the agile model driven development:

1. The agile models do not fulfill their purpose well.
2. It is very difficult to understand the agile models.
3. The agile models do not exhibit sufficient consistency.
4. The agile models are not sufficiently detailed.
5. The accuracy of the agile models is not so high.
6. The agile models exhibit a characteristic complexity.
7. Sometimes negative values are provided by the agile models.

Point of Argument

- Another most argued concept of agile model driven development is that the agile documents and models seem to be sufficient for carrying out the development.

- For this, the people develop false assumptions that the software is not as good as it portraits and expectations regarding the quality of the software artifact. 

- It is also thought that if the artifact has fulfilled the purpose which was intended then any more work that can be carried out on it is considered to be a useless bureaucracy. 

Benefits of Agile Model Driven Development

- The agile model driven development is known to take a more realistic approach and give a description of how the developers and stake holders are supposed to work together in cooperation to create good models.

- Agile model driven development is quite a flexible technology in the way that it allows the use most primitive and unsophisticated development tools for the creation of the models like papers and white boards as mentioned above.

- The agile model driven development is supposed to be independent of any sophisticated CASE tools even though they can be used effectively by the experts. 

How is test driven development and documentation linked?

As we all know that the test driven development or TDD is another process in the list of the most of the popular software development processes. The topic of the test driven development is in the league of this article. 

About Test Driven Development

- The test driven development took its root from the idea of the repetition of a very short development cycles. 

- The first of all a failing automated test case is written or created by the software developer or tester which is meant to serve the purpose of defining a new function or a desired improvement. 

- Secondly a code to pass the above created test is also written by the developer. 

- This newly written code is then subjected to refactoring in order to make it meet the acceptable standards. 

- The test driven development has always been looked up as an encouragement for the simple designs and also as an inspiration for boosting up the confidence levels.

- The test driven development has always been known to be related to the concepts of the extreme programming or XP. 

- But, eventually it came to be known as a standalone process having its own ways and rights.

- The concepts of the test driven development are used by the programmers and developers as a measure for debugging the legacy code and improving it further. 

- The test driven development is usually driven by a series of automated unit tests that are written by the developer to provide definition for the requirements of the code and then the code is automatically produced. 

- These tests are constituted of the assertions of their own.

- If a test is successfully passed, the developer is confirmed of the correctness of the code and that it can be further evolved and refactored. 

The documentation forms a very important part of any development or testing and so does of the test driven development. This article has taken up the question: “how is test driven development and documentation linked?”. 

About Importance of Documentation In TDD

Now coming to the importance of documentation in the test driven development, it includes the following documents:

1. Feasibility report
2. Technical documentation
3. Operational documentation
4. Log book and so on.

- The documentation in test driven development is another source of support to the developers as well as the users.

- It provides all the crucial information required to set up a uniform environment in which the software system or application is to be operated. 

- In case of a break down when the person in charge is not available, the users experience down time and most of their resources are wasted. In such situations, there is only one thing that can save one’s precious time and efforts and that thing is nothing but the documentation. 

- It provides all the information and guidelines that are required to fix an issue. 

- The format of the documentation does not matter much as much as it content matters.

- Documentation is vital to any software development process and not particularly to the test driven development.

- Documentation is an effective mean for streamlining the test driven development process. 

- Apart from all this, documentation has got an important role to play in the business.

- Document is needed in the test driven development since it helps in codifying the procedure for the development of the software system or application. 

- The documentation provides effective protection during the audits to the test driven development.

- It is important that the documentation is developed alongside the development of software system or application. 

- Documentation will be effective if it is considered to be a part of the work and not a hindrance to it.