What is the role of testing frameworks and automated scripts in refactoring?

Re-factoring is one of the most disciplined techniques which very well save use from the drudgery of rewriting the program code for software systems and applications. 

About Re-factoring

- Re-factoring is a technique that facilitates the restructuring of the existing body of the program code by carrying out alteration in the internal structure of the software system or application.

- The best thing about re-factoring is that even if it does make changes to the internal structure of the software system or application, the external behavior of the system under question is not at all affected.

- Re-factoring is quite in demand during the testing phases since it helps a lot in improving the non functional attributes of the software system or application. 

- Typically, a part of the software system or application is changed by the application of a number of re-factorings which constitute a little change in the program’s source code which does not needs any modification in its functional requirements. 

There are so many advantages of refactoring like some of them mentioned below:

1. It improves code readability
2. It reduces complexity
3. It improves maintainability
4. It improves extensibility.

When the design of a program’s code is continuously improved, it gradually becomes easy to work with. Usually what we do is pay a lot of attention to the addition of the new features and functionalities and we do only a little refactoring. As a consequence of the software system or applications becomes quite clumsy in its working. 

"The good habit is to refactor a lot in ratio with the expedient addition of new features and functionalities. Refactoring your system now will help you maintain and extend it in the later stages of the software development whenever you want. If the testers fail to refactor the program code they will have increased technical debts."

Role of Testing Frameworks and Automated test scripts in Re-factoring

- Test frame works and automated test scripts have got a lot to do with the refactoring process. 

- Some solid sets of automatic unit tests are a priority before you start refactoring the program code. 

- These tests are in turn are generated using a test automation frame work and testing scripts. - These automated tests are so quick that it only takes a few seconds for them to execute and tell whether or not the respective program module is working properly. 

- This process is like going through the following steps:

1. Make a small program transformation.
2. Test it to ensure its correctness.
3. Make another small transformation.

- It seems like an iterative cycle, isn’t it? 

- Suppose at some point the test fails, then the last change that was made is undone and redone in some different ways and again subjected to testing. 

- It is like moving the program from where it is to where you want to be in small small steps. 

- This process forms an integral part of the software development life cycle. 

- A number of general frameworks have been designed to make the process of refactoring effective and efficient. 

- A refactoring tool must be able to refactor the code that is written under a particular testing frame work. 

However there are certain aspects without addressing which refactoring cannot be achieved:

1. Naming conventions
2. Meta programming aspects
3. Call back functions and so on.

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”.

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. 

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. 

Can Test Driven Development (TDD) work for data-oriented development?

Today the test driven development is quite a familiar concept among the developers and testers in the field of software engineering and technology and so is the data oriented development. 

Data oriented development is commonly known as the object oriented development. We have taken up an important question in this article which is “can test driven development work for data oriented development?”

But before answering this question we shall discuss about the two different developments involved in the question individually so that the understanding of the answer becomes easy. 

About Test Driven Development

First let us discuss about the test driven development. The test driven development as the term itself suggests is based up on carrying out the development process with the help of short development cycles that include the following steps:

1. Addition of a test: The development begins with the creation of test cases for all the features.
2. Execution of all tests in order to check the working of the new one.
3. Production of code implementing which the code can only pass the test and does not incorporates any new functionality.
4. Execution of the automated tests and observing their success.
5. Re-factoring or cleaning up of the code
6. Repetition of the whole cycle for the improvement of the functionalities.

Many development styles have been developed for the test driven development few of which are mentioned below:

1. YAGNI (you ain’t gonna need it),
2. KISS (keep it simple stupid),
3. Fake it till you make it and so on.

About Data Oriented Development

- It makes use of the models that are developed around the real world concepts.

- This development methodology involves the incorporation of the data behavior as well as the structure. 

- The process starts from the quantization of the data in to small distinguishable and discrete entities which are known as the “objects”. 

- Each of the objects created have their own inherent and unique identity. 

- Other characteristics of the data oriented development aare:

1. Classification
2. Inheritance
3. Polymorphism

- The essence of the object oriented development lies in the organization and identification of the application concepts.

- The primary focus lies with the analysis and design phases. 

- The data oriented development is known for encouraging the software developers to work and think. 

- This can be thought of as a conceptual process independent of a programming language. 

- The methodology here is to build the software model and add details to it during the design. 

- It consists of the following steps:

1. System conception
2. Analysis
3. System design
4. Class design and
5. Implementation

Can TDD work for Data Oriented Development

Now coming to our question, the answer is yes test driven development can absolutely work for the data oriented development since it has many characteristics and benefits that can be successfully incorporated in to the data oriented development:

1. Predictability: With the test driven development it is easy to predict that when the development process if finished since all the tests that they have are passed by the code.

2. Learning: With the test driven development the developers get a better understanding of the code and hence it becomes easier to develop the code that models the real world very well.

3. Reliability: Moreover the test driven development makes the data oriented development more reliable since it has a suite of regressions tests that cover all of the system aspects.

4. Speed: With the test driven development the data oriented development can be speeded up since a little time is spent debugging and mistakes are sought very soon.

5. Confidence

6. Cost

7. Scope limiting

8. Manageability

9. Documentation

Compare Test Driven Development and Traditional Testing?

Till many years the traditional testing was in use until there was a rise of another software development strategy or process called the test driven development. These two development processes are in great contrast to each other. 

This article is focussed entirely up on the differences between the two types of development i.e., the traditional testing and the test driven development. So let us begin by describing the test driven development. 

About Test Driven Development

- The test driven development process is comprised of the repetition of very short development cycles.

- By short here we mean the development cycles in the test driven development are shorter than the usual normal cycles. 

- These development cycles comprise of the following tests:

1. Production of code: This step involves the creation of some code implementing which the code can only pass the test and does not incorporates any new functionality.
2. Execution of the automated tests and observing their success.
3. Re-factoring of code: This step involves the cleaning up of the code.
4. Repetition: The whole cycle is repeated for the improvement of the functionalities. 

- The test driven development was considered to be somewhat related to the test- first programming concepts of the extreme programming long since. 

- After that it came to be as an individual software development process. 

- The test driven development has prove to be quite effective for developing ad improving the legacy code that has been developed using the older development techniques. 

- So many development styles for the test driven development have been identified like those mentioned below:

1. Fake it till you make it
2. Keep it simple stupid or KISS
3. You ain’t gonna need it or YAGNI

- In the test driven development the primary focus is on writing the code which is necessary only to pass the tests to keep the design clean and clear of the fuzz.

About Traditional Testing

 Now coming to the traditional development methodologies or approaches, they are commonly called as the engineering approaches and they were defined at the very beginning of the software sciences. 

- Traditional development methodologies were developed to control the software development processes via a disciplined approach whose build and the stages were predictable.

- In the traditional software development methods, the stages of analysis and design precede the stage at which the software is build. 

- Unlike the test driven development process, these traditional development process are well documented .

- Their main disadvantage is that they are quite difficult to apply because of their complexity.

- Another disadvantage being that the traditional development methodologies are bureaucratic.

- In practical, these traditional development processes often cause a high level of complexity in the software system or application. 

- In traditional approaches there are two main stages namely:

1.      Stage of analysis and

2.      Stage of design

-The foundation of the whole project depends up on these two stages, therefore it is necessary that adequate focus is on these two stages and more and more efforts should be put on these stages. 

- For the project to be successful it is important that the traditional method is applied in the right way.

- Designing is considered to be a highly creative activity. 

- It becomes very difficult to plan and predict these complex methodologies as the level of their creativity increases. 

- The main feature of the traditional development processes is the detailed planning and designing phase. 

- Traditional development holds good when it comes to undertaking very large projects involving higher risk. 

- One more commonly observed thing is that the projects development with the traditional methodologies last longer. 

Explain Test-Driven Development Cycle?

Test driven development or TDD is considered to one of the most effective as well as efficient software development methodology or process that is often cited under the category of the agile software development processes.

The term “test driven development” is self justifying as one make out from the term itself that it is driven by the tests. Actually, the test driven development process is wholly based up on the repetition process of the several development cycles that are shorter than the usual development cycles. 

This whole article is dedicated to the discussion regarding the test driven development cycle. 

What are the steps in TDD process?

Test driven development process involves the below mentioned steps:

1. First step involves the creation of an automatic test case that is failing and defines a new function or some desired improvement in the code.

2. Second step involves the production of code which can pass the test.

3. Third and the final step involves the re-factoring of the new code in order to meet the prescribed standards.

This development strategy or process was introduced in the year of 2003 by Kent beck. The first programming concepts of the extreme programming or XP are considered to be related to the concepts of the test driven development to some extent.

But, nowadays the test driven development has been observed to be an individual development methodology with its own rules and independent procedures. The test driven development process has proved to be successful in improving and debugging legacy code that has been developed using the older development techniques. 

We all know that every development process has its own requirements so here in this the requirements are the automated unit tests that provide a definition of the code requirements and create the associated code themselves. 

Test Driven Development Cycle

Now let us describe the test driven development cycle in detail and sequence:

1. Adding of a test: 

- In test driven development, for every feature to be added, first a test is written that is inevitably expected to fail since it is written before the actual implementation of the features. 

- If the test does not fail, then there are two probabilities: the test is either wrongly formulated or the feature for which the test has been created already exists. 

- The test should be written with utmost understanding of the specifications and requirements which can be achieved from the use cases and user stories. 

- An already existing test can also be modified.

- Writing unit tests before the implementation of the feature helps the software developer or program focus up on the requirements before the actual code is written. 

- This feature of the test driven development differentiates it from the others and leaves a subtle and important effect.

2. Execution of all the tests and check if they fail: 

- This step involves the validation of the test harnesses for their proper working.

- This is done to ensure that no test passes mistakenly without requirement of new code. 

- The test itself is also tested but in the negative so that all the possibilities of passing of the new test are ruled out making it worthless.

3. Production of code: 

- This step involves the production of code by virtue of which the test will pass.

- The code even if its no perfect is accepted since later it can be improved.

4. Execution of the automated tests: 

After all the tests have passed, the developer can be confident that the code is perfect.

5. Refactorization of the code: 

This involves clean up drive of the code and the tests can be re- executed in order to ensure that the existing code is not being damaged.

6. Repetition: 

This involves repetitions of the whole development cycle in order to improve functionality.