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 Code Division Duplexing?

CDD or the Code Division Duplexing is a duplexing system that is perhaps the most spectrum – efficient one. In this article we discuss about this system. 

But first let us look at the scenario of the spectrum efficiency. 

- Elimination of interference is very complicated as well as an important issue when it comes to the implementation of the wireless communications. 

- With the increasing spectrum efficiency, interference becomes compulsory to be eliminated.

- Reducing the interference is very much important in order to increase the transmission data rate and the radio capacity of the wireless communications. 

- By duplexing, we mean that using two separate channels for the transmission of information in a two way communication in two different directions. 

- Currently we have only two working technologies in this regard namely:

1. Frequency division duplexing or FDD and
2. Time – division technology or TDD

- The former is the primary technology used in wireless because of its characteristic ability of interference isolation.

- The latter is kind of a spectral efficient technology.

- At present, frequency–division duplexing or FDD is mostly used by all the cellular systems for eliminating the interference that occurs in the adjacent cells. 

- A number of technologies are used today that have been successful in limiting the effects of the interference. 

- But they have not been successful in eliminating two particular types of interference namely:

1. Adjacent base – to – home mobile interference and
2. Adjacent mobile – to – home base interference

- Time Division Duplexing or TDD has not been put to use for the cellular systems since this one is much susceptible to different types of interference  

- TDD is not just subjected to the above mentioned two forms of interference rather it faces additional adjacent mobile to home and base to home interference.

- This limits the use of time division duplexing to the systems confined to a small area. 

- In Code–Division Duplexing, all these types of interference are eliminated making it the most spectrum efficient one. 

- However, proper CDD systems are not a perfect reality yet.

- CDD represents an innovative solution.

- Another best multiple access scheme is the CDMA (code – division multiple access) since it is more effective in eliminating the interference when compared to the other technologies. 

- Code – division duplexing is a combination of TDD and smart codes. 

- The CDD can be turned in to reality only with these smart codes. 

- CDMA based on these smart codes is termed as LAS – CDMA where LAS represents the smart codes set. 

- This technology holds the promise for increasing the spectral efficiency as well as capacity of the mobile networks. 

- For the efficient utilization of the spectrum, two technologies are required:

1. A multiple access scheme and
2. A duplexing system

- The industry has already established CDMA as the best out of three available (the other two are FDMA and TDMA). 

- Next, a duplexing system remains to be selected. 

- FDD has been the most common choice till now. 

- It makes use of different frequencies for handling the outgoing and incoming signals. 

- On the other hand, TDD operates on a single frequency but uses different time slots. 

- Using a TDD system provides a benefit of alternating sending and receiving in a single frequency. 

- Smart codes ensure that the code–division duplexing system is not like TDD but much better than that. 

- An interference limited environment was generated by the cellular systems using multiple frequencies in multiple cells. 

- Later, cells started using same frequency but still the environment was interference limited. 

- But the CDD system promises to change this environment in to one that is noise limited. 

Some detail about usage of work products in extreme programming?

Extreme programming or XP gained popularity as one of the most effective agile software development practices in the late nineteen’s. This methodology came in to existence for the purpose of the implementation of the software projects using the 12 predefined practices.

These practices are a refinement of the best practices of the software engineering. The whole process is intended in making improvements to the quality of the software system and its ability to respond to the needs of the customer. 

The frequent releases of the software system or application are regulated by the iterations or the short development cycles. There are certain elements of the extreme programming which include:

    1. Pair programming

    2. Extensive code reviews

    3. Unit testing of the whole code

    4. Avoiding programming of the features and functionalities that are not required at the moment.

    5. Keeping a flat maintenance structure.

    6. Maintaining clarity as well as the simplicity in the code.

    7. Expecting changes in the requirements of the customers.

The above mentioned elements make the whole development process all better. During Kent Beck’s work on his C3 (Chrysler comprehensive compensation system) pay roll project, he developed this agile software development methodology. 

Extreme is nothing but as the name suggests, a process of implementing the best practices of the software engineering to the highest levels possible. Extreme programming has always been surrounded by a lot of buzz regarding the environments in which it was used and is being used. 

Its practices always demands high discipline making them appear to be so rigid. On the other hand if an approach is quite flexible and less rigid, schedule makes it easy to incorporate complex features in to a fully developed software system or application. 

The practice continuously integrating the whole software system helps a big deal in keeping the whole development on the right track. With its 4 activities (namely coding, testing, listening and designing) the extreme programming is aimed at achieving the below mentioned goals:

1. Organize the people to produce software products with high quality and productivity.
2. Reduce the cost of the changes in the customers’ requirements with the multiple short development cycles.
3. Define changes as the natural and desirable aspect of the software projects.

About Work products in Extreme Programming

This article is focused up on the work products of the extreme programming. In one research it was found that the extreme programming helped in many of the projects in reducing the costs and time to market the software products and improved the productivity.  

- Describing the work products of a software methodology helps in checking out the problems of the interpretation.

- Extreme programming is not a small methodology therefore it involves a large number of intermediate work products. 

- But to say as a whole, the work products are quite necessary.

- People who are just beginning with the extreme programming need to know what are actually acceptable work products. 

- The stake holders need to know what they are entitled to ask for. 

- Three work products are mentioned that are typical to an extreme programming development process. 

- The number of the work products depends on how they are counted. 

- In the extreme programming the work products are distributed across the roles i.e., to say they are light. They are:

1. System architecture
2. Common domain model
3. Screen drafts

- There are dozens of the work products and doing each of them might be a hectic work! But on the other hand if you skip out many of them your project will lose its visibility as well as its alignment.

- You cannot pick some core work products since even lose of one product can hamper the whole project development. 

What are the core practices of extreme programming?

Over the time the extreme programming has proved itself to be a great helping hand as an agile practice in improving the overall quality and productivity of the software products according to the ever changing requirements of the customer.
Being an agile practice it frequently releases software products with the short development cycle which is achieved through time boxing. During the whole process several check points are introduced in to the development cycle where the new customer requirements can be easily incorporated in to the software system.

Elements of Extreme Programming

There are several elements of the extreme programming like:
1. Pair programming
2. Extensive code review
3. Unit testing
4. Maintain simplicity and clarity of the code
5. Providing a flat management structure and so on.

Values of Extreme Programming

The extreme programming is guided by values, rules and principles! There are 5 values namely:
1. Communication
2. Simplicity
3. Feedback
4. Courage
5. Respect

Principles of Extreme Programming

The rules of the extreme programming govern its all time activities. Three basic principles have been defined for the extreme programming as mentioned below:
1. Feedback
2. Assuming simplicity
3. Embracing change

core Practices of Extreme Programming

The extreme programming is said to be composed of 12 practices which is what we going to discuss in this article. The 12 practices have been grouped into sets of four:

1. Fine Scale Feedback: This area involves 4 following practices:
(a) Programming in pairs: This agile practice involves 2 programmers working side by side one of which is a driver and other is an observer. The driver is suppose to type in the code while the observer holds the duty to review each line of the code typed.

(b) Planning game: This is the most important practice in the extreme programming. The game here is the name given to a meeting that is held once for every iteration of the development process with the purpose of guiding the product in to delivery. It has 2 parts:
- Release planning: It has 3 phases:
    + Exploration phase
    + Commitment phase
    + Steering phase
- Iteration planning: It too has got the same phases as the release planning.

(c) Test driven development or TDD: This is another agile practice relying on the iterative and incremental approach and refactoring of the code for improving its overall design.

(d) Whole team: Extreme programming forces the need of the customer availability at all the times for questions.

2. Continuous Process: This process is constituted of the following 3 practices:

(a) Continuous integration: In extreme programming it is required that only the latest version of the software system or application is worked up on.  The current version of the software that is available with the different team members must be uploaded to the code repository in every few hours since this avoids delays in the project cycle.

(b) Design improvement or re-factoring of the code: Since only the required functionalities are implemented, this may cause the system to hang. This may require dual maintenance then. In such cases changes in one part of the program affect the other parts of the code. At such times the refactoring of the code is needed.

(c) Small releases: The software is delivered via the frequent releases of the live functionalities. With these small releases the customers gains the confident about the progress of the development and the concept of the “whole team” is also maintained. The customer as well is able to come up with the suggestions regarding the development of the software.

3. Shared Understanding: This involves the following 4 practices:
(a) Coding standards
(b) Collective code ownership
(c) System metaphor
(d) Simple design

4. Programmer Welfare: It involves development at a “sustainable pace”.

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. 

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.