Also, to get full credit for the assignment you must comment on at least three of the postings of other students in the class. Write comments when you have strong agreement or disagreement with their postings or when you have questions about their answers. Also, please respond to the comments others post regarding your answers.

If you wish you may use an alias instead of your real name. Also, there is no need to give your email address when requested to do so. Just be sure to give me your alias when you turn in the hardcopy of your original postings.

You will be graded on both the quality of your orignial postings and that of your responses to the postings of others.

Messages [ Show Index ]

Question 1 Date: Sep 03, 12:16 From: Prof. Lingard

How would you describe (in 25 words or less) the concept of “test-driven development”?

re: Question 1 Re: Question 1 (Prof. Lingard) Date: Sep 09, 20:03 From: EricD

TDD requires tests to be written before code because designing tests helps define how a program and its interfaces should behave.

re: re: Question 1 Re: re: Question 1 (EricD) Date: Sep 12, 21:48 From: Anthony Arnold

It's a good point you bring up about the software interfaces. That's where I think the strongest advantage of TDD is, defining good, testable interfaces. The details of the transformations of data within the software units is probably more likely to change than the interfaces to the units.

re: Question 1 Re: Question 1 (Prof. Lingard) Date: Sep 11, 13:26 From: Eduardo Borjas <eduardo.p.borjas@csun.edu>

The technique of writing automated unit tests that forces requirements knowledge before writing atomic code and executing those tests on the code to improve quality.

re: Question 1 Re: Question 1 (Prof. Lingard) Date: Sep 12, 14:24 From: Peter Guy

Test Driven Development is the practice of using pre-written test cases for simple program units to drive design, clarify specifications and inform implementation.

re: Question 1 Re: Question 1 (Prof. Lingard) Date: Sep 12, 15:25 From: Martin

TDD is the process of first creating tests for all of the requirements, write code that will satisfy these tests, and refactor.

re: re: Question 1 Re: re: Question 1 (Martin) Date: Sep 12, 16:01 From: Peter Guy

I like the fact that you included refactoring in your description, Martin. I tried to, but ran out of words. :-) Refactoring is an integral part of the programming models that use TDD.

re: re: re: Question 1 Re: re: re: Question 1 (Peter Guy) Date: Sep 15, 22:21 From: Martin

I agree, however I also believe that refactoring is one of those tasks that can get thrown to the side when schedules get closer and developers get swamped.

re: Question 1 Re: Question 1 (Prof. Lingard) Date: Sep 12, 16:56 From: Anthony Arnold

TDD is a software practice where unit test are always written before coding. After being written, the code's design is refactored while passing tests.

re: Question 1 Re: Question 1 (Prof. Lingard) Date: Sep 12, 22:09 From: Cristian U. <christianurs@yahoo.com>

TDD requires writing automated tests before writing code which will force the focus on interface, interaction between objects and design through refactoring.

re: Question 1 Re: Question 1 (Prof. Lingard) Date: Sep 13, 14:04 From: The B00giem0n <benjamin.riveira.832@csun.edu>

Test-driven development is a practice in which software unit tests are written even before developers code the methods and/or classes to be tested.

re: Question 1 Re: Question 1 (Prof. Lingard) Date: Sep 13, 19:26 From: win <win.phyoe.58@csun.edu>

TDD is a practice requiring to develop tests before writing the code. Then refactoring the passed code to improve the software quality.

re: Question 1 Re: Question 1 (Prof. Lingard) Date: Sep 15, 09:31 From: Troy Mockenhaupt <troymock88@yahoo.com>

Test Driven development is simply the process of designing test cases for software before any programming, then using the results to help improve the process of development.

re: Question 1 Re: Question 1 (Prof. Lingard) Date: Sep 15, 15:53 From: Edfan T

TDD is a practice of writing automated tests that specify and validate what the code do; done before coding and followed by refactoring.

re: Question 1 Re: Question 1 (Prof. Lingard) Date: Sep 15, 23:39 From: Anusha <anusha_nataraj@yahoo.com>

Test Driven Development (TDD) is a software development technique where an automated unit test is written for each functional unit before enough code is written and refactoring.

re: Question 1 Re: Question 1 (Prof. Lingard) Date: Sep 16, 01:47 From: David H

1.Test Driven Development is a practice by which the entire software development process is driven by test cases created by developers.

re: re: Question 1 Re: re: Question 1 (David H) Date: Sep 20, 22:33 From: Eduardo Borjas <epb55720@csun.edu>

I think you need to also state that the testing is unit based. Writing test cases can be done in many ways (unit, regression, system, etc) so I would think you'd have to be more specific. Also why are test cases being written? Software quality is the answer.

re: re: Question 1 Re: re: Question 1 (David H) Date: Sep 23, 12:46 From: Harvey Alexian <xharvey-ax@sbcglobal.net>

I don’t think necessarily TDD applies to the entire software development process. It can be applied to certain parts of a big software development project , as many companies have done that, without affecting the other parts of it, because this methodology is unit-task based so we can easily use in different parts of the software project.

re: Question 1 Re: Question 1 (Prof. Lingard) Date: Sep 16, 13:42 From: Harvey Alexian <xharvey-ax@sbcglobal.net>

TDD as a programming practice is mainly used with eXtreme programming (XP),in which a proposed piece of software is broken down into smaller "Tasks" and a programmer starts by wrting some test cases for that specific task.

Question 1 Re: Question 1 (Prof. Lingard) Date: Sep 16, 14:04 From: Alireza B. Shad <alireza.shad@csun.edu>

1. The Test-Driven Development, TDD, involves testing every functional components of a program before the actual coding. This is an automated on-going testing tactic that allows the programmers to use test-cases right before actual coding of a program, rather than manual testing of the actual code.

re: Question 1 Re: Question 1 (Prof. Lingard) Date: Sep 16, 14:04 From: Jerry

TDD in software development relies on the repetition of a very short development cycle. It requires pre-written test cases before coding.

Answer Re: Question 1 (Prof. Lingard) Date: Sep 16, 14:07 From: Arastu Shah <arastujshah@gmail.com>

It is a way of core extreme programming development, leading analysis, design and programming decisions, in which you write automated tests before you write the functional code in small iterations with little upfront design. The goal of TDD is ‘clean code that works.’

re: Question 1 Re: Question 1 (Prof. Lingard) Date: Sep 16, 15:02 From: Ricardo Miron

Test driven development is a software development practice that reduces the effort of testing by writing automated unit tests prior to the code under test

re: Question 1 Re: Question 1 (Prof. Lingard) Date: Sep 16, 15:19 From: Jack Weaver <weaver.jack@gmail.com>

TDD is a process which is employed to lower code defect rates. It's key idea is to write test cases first, then write the code that passes the already-written test cases.

re: re: Question 1 Re: re: Question 1 (Jack Weaver) Date: Sep 22, 18:39 From: David H

I think its probably too specific to say its goal is to lower defect rates. I think there is a lot more to it than that. For example, it could also shorten development time.

re: re: re: Question 1 Re: re: re: Question 1 (David H) Date: Sep 23, 17:07 From: Jack Weaver <weaver.jack@gmail.com>

Of course, but there's only so much you can say about it in 25 words :-).

re: Question 1 Re: Question 1 (Prof. Lingard) Date: Sep 16, 17:28 From: Velimir

TDD is a process of developing software after developed a test case for the software component. TDD produces a better code because every smaller component(unit) of the code is already tested and if this unit isn’t functioning properly it is refactored right away , rather then being refactored when the whole unit is completed. The second approach may create more bugs by fixing a bug. TDD minimizes this possibility.

re: Question 1 Re: Question 1 (Prof. Lingard) Date: Sep 16, 18:34 From: Anna Brjezovskaia <Anna.Brjezovskaia.509@csun.edu>

TDD is a software development technique, which supports analysis and design of software. It demands the automotive test cases to be written before the actual coding.

re: Question 1 Re: Question 1 (Prof. Lingard) Date: Sep 16, 22:50 From: Nick Terani

TDD is a practice incorporated within agile process models, most commonly Extreme Programming which helps guide the analysis, design, and programming decisions through automated test cases.

re: Question 1 Re: Question 1 (Prof. Lingard) Date: Sep 22, 10:02 From: Omer

TDD is a direct outgrowth of that part of Structured Programming, Programming by Contract, and Object Oriented Design and Programming where a function or method is defined by its inputs, its outputs, and the contracted transformation between them. Using TDD one has to formalize these factors into tests before coding the transformation.

re: re: Question 1 Re: re: Question 1 (Omer) Date: Sep 22, 20:46 From: Ricardo Miron

I like your definition, but I would mention the use of automated tests to test units of code.

re: Question 1 Re: Question 1 (Prof. Lingard) Date: Sep 28, 21:57 From: Sphoorti Madugula

TDD involves writing automated tests for each bit of functionality in the production code that specify & validate what the code will do; producing code accordingly to enable the tests to pass; refactoring the production & the test code. (Notes for reference in the future…) TDD involves writing automated tests for each bit of functionality in the production code that specify & validate what the code will do, so as to drive design & programming, then producing code accordingly to enable the tests to pass, finally, changing the structure of the existing body of code without changing its external behavior, in other words, refactoring the production & also the test code. TDD: » Is an integral practice in agile methods. » Enables design through refactoring (after which the test still passes, but the code is cleaner), collective ownership, continuous integration and programmer courage. » Unit tests written prior to the code under test can be executed right after the code is written, a vital component of the development process, providing feedback quickly if and when changes are made to the code. » Mainly used in eXtreme Programming (XP). » Relies on the repetition of a very short development cycle. » Employed to lower code defect rates. » Minimizes the possibility of creating more bugs in the process of fixing existing ones. » Forces focus on the interface and interaction between objects.

Question 2 Date: Sep 03, 12:17 From: Prof. Lingard

What questions do you have after reading this paper, i.e., is there anything you didn’t understand or would like a more complete explanation of?

re: Question 2 Re: Question 2 (Prof. Lingard) Date: Sep 09, 20:10 From: EricD

Other than Java/JUnit/xunit, which TDD tools exist, particularly for c/C++/C# development. What sort of tests are designed? Are they simply Assert statements to check variable values, or do they check program flow?

re: re: Question 2 Re: re: Question 2 (EricD) Date: Sep 13, 15:15 From: The B00giem0n <benjamin.riveira.832@csun.edu>

Several tools are available to support unit testing under Visual Studio/.NET architecture: the NUnit Framework, the MbUnit Framework coupled with the Gallio Automation Platform, TestDriven.Net, and last but not least, the Unit Testing framework in Visual Studio Team System.

re: re: Question 2 Re: re: Question 2 (EricD) Date: Sep 13, 22:36 From: win

According to the link http://www.agiledata.org/essays/tdd.html I have found, the followings are the available tools for TDD. •cppUnit •csUnit (.Net) ) •CUnit •DUnit (Delphi) •DBFit •DBUnit •HTMLUnit •HTTPUnit •JMock •JUnit •NDbUnit •NUnit •OUnit •PHPUnit •PyUnit (Python) •TestNG •Test::Unit (Ruby) •VBUnit •XTUnit

re: re: Question 2 Re: re: Question 2 (EricD) Date: Sep 13, 22:48 From: win <win.phyoe.58@csun.edu>

According to the link http://www.agiledata.org/essays/tdd.html I have found, the followings are the tools for TDD. •cppUnit •csUnit (.Net) •CUnit •DUnit (Delphi) •DBFit •DBUnit •HTMLUnit •HTTPUnit •JMock •JUnit •NDbUnit •NUnit •OUnit •PHPUnit •PyUnit (Python) •TestNG •Test::Unit (Ruby) •VBUnit •XTUnit

re: re: Question 2 Re: re: Question 2 (EricD) Date: Sep 16, 15:06 From: Ricardo Miron

Is the time to market necessarily longer for a project using TDD as opposed to one that doesn't?

re: Question 2 Re: Question 2 (Prof. Lingard) Date: Sep 11, 13:28 From: Eduardo Borjas <eduardo.p.borjas@csun.edu>

How do you manage TTD? o How is the quality of each automated unit test evaluated? o How do you make sure that all developers are following the TTD methodology? o How do you make sure that all portions of the code have automated unit tests? o Is there a level of TTD done above the unit test (for example a program using a database management system or a cluster application) or is TTD strictly managed at the unit level? Why is it not preferred that a partner programmer (pair programming is a part of XP) or other developer write the unit tests? Since one of the fundamental reasons why testing is given to SQA is due to the fact that a developer may be blind to some aspect, wouldn’t they be just as blind using TTD? Are their different levels of TTD that can be implemented? For example maybe only enforcing TTD on junior level programmers (in the article it states that it reduces their defects more than 50%) or only using TTD on high-risk portions of the code. If so, what improvement gains/losses do we have over the extreme every unit must be tested methodology. If TTD is the preferred way of testing products from an agile or highly iterative project management life cycle, isn’t it a bit counter intuitive to write tests that may be completely wrong later? If a feature has to be radically changed, doesn’t that mean that all the unit test cases affected by the new feature need to be updated as well? How inefficient is that?

re: re: Question 2 Re: re: Question 2 (Eduardo Borjas) Date: Sep 23, 15:51 From: Alireza B. Shad <alireza.shad@csun.edu>

very good questions Eduardo. with respect to the evaluation of the unit test, I beleive, the quality will be masured by testing various cases. if the unit test covers all cases that may occur, then I beleive we can have a good quality unit test that results to detection of defects.

re: Question 2 Re: Question 2 (Prof. Lingard) Date: Sep 12, 14:47 From: Peter Guy

I would like to learn more about the concept of "programmer courage" that is mentioned in paragraph two, then again on page four. I think I understand the general idea - taking the fear out of making code changes - but I'm interested in the details and in how it fits into a programmer's worldview. After reading this article, I was curious about how TDD fits into programming models, so I googled around a bit and found several other blogs, articles, etc... discussing TDD and Agile Programming. One find was particularly useful - a recorded interview of Scott Bellware by Scott Hanselman (http://www.hanselman.com/blog/HanselminutesPodcast146TestDrivenDevelopmentIsDesignTheLastWordOnTDD.aspx). They discuss many aspects of TDD and how it fits into programming models. Their primary topic was TDD as a design tool. The interview was very informative because it talked about the other pieces of programming philosophy necessary to make TDD work: small simple functions, code "testability", "solubility" of a design, transparent dependencies, and so on. One concept that struck me as particularly important is that if the test is obtuse or complicated, you should question the design, and perhaps even the code used to implement the design. Their term for this is "smell" - if the test smells, then the design smells, and probably the code smells as well. What this means is that if your design cannot be easily used, it needs to be reconsidered. I would still like more details of how TDD fits into different programming models. Pictures would be nice.

re: re: Question 2 Re: re: Question 2 (Peter Guy) Date: Sep 15, 19:47 From: Troy Mockenhaupt <troymock88@yahoo.com>

I think you bring up a good point about programmer courage. It seems like something that could improve the process, but in my opinion the author was very vague in any explination of this. I would agree with you in that i would like to know more about this.

re: re: Question 2 Re: re: Question 2 (Peter Guy) Date: Sep 16, 21:58 From: Arastu Shah

I like your idea Peter. I would like to have more details about programmer courage as well.But I my understanding of it is that when programmers take part in writing tests for their code,they get a better understanding of what they are going to code and test.This increases their courage and confidence. They will hesitate less when making a change if some code doesn't work right or doesn't perform the way it should. The developers will take responsibility of their code and its output too.They will better understand the design before coding. This all leads to higher productivity and more efficiency.

re: re: re: Question 2 Re: re: re: Question 2 (Arastu Shah) Date: Sep 19, 12:09 From: Peter Guy

I like how you brought responsibility into the picture, Arastu. Seems that courage and responsibility go hand-in-hand.

re: re: Question 2 Re: re: Question 2 (Peter Guy) Date: Sep 22, 20:25 From: Ricardo Miron

After reading the article that you linked I am now willing to change my stance that TDD is suitable for a large scientific project.

re: re: Question 2 Re: re: Question 2 (Peter Guy) Date: Sep 23, 15:45 From: Jerry

I agree, but I want to expand more on the idea. I think by making the tests automated rather than manual, it free up a lot of the programmer’s time to do other things like design, debug, and able to change the code without the fear of the lack of the time.

re: Question 2 Re: Question 2 (Prof. Lingard) Date: Sep 12, 17:02 From: Anthony Arnold

The integration of TDD into the software design is not well addressed in this article. TDD prescribes always writing unit tests before designing and coding. However to be able to write unit tests, one would have had to at least do architectural/system level design work to break the system down into small enough components to test. This is not a trivial effort, but is not calculated into the potential saving of doing TDD. If you assume that there was no architectural/system level design, then it appears as though the unit tests are somewhat written haphazardly directly against the highest level customer requirements. Maybe I am not understanding how TDD is supposed to play into design and coding? Another area that's not clear is exactly what level of requirements are expected to be able to perform TDD. It may be that the level of requirements detail and maturity is dependent upon the software development model that is being used (i.e. Spiral, Agile, etc). However I would think that the requirements would have to be fairly well defined in order to start writing unit tests, otherwise there would be a lot of rework of the unit tests themselves, which as the article points out would also cause the actual code to need rework.

re: re: Question 2 Re: re: Question 2 (Anthony Arnold) Date: Sep 15, 22:43 From: Martin

Good points. I agree with your view that some design must be done ahead of writing tests and coding. I have been on a project that uses TDD and we did a high level design first, that way when we divided the requirements or features up into teams we were all on the same page. Without that upfront design, each team would be duplicating work of base classes or other high level design.

re: Question 2 Re: Question 2 (Prof. Lingard) Date: Sep 13, 13:28 From: Cristian U. <christianurs@yahoo.com>

2. I was wondering how reusability works in TDD? If I am developing a huge enterprise application how do I realize which functionality belong to the architecture if I am not doing the design first? Also, how does TDD scale with databases development or web based GUI ? Lastly, how TDD will work in a programming language which doesn't have any integrated unit test?

re: re: Question 2 Re: re: Question 2 (Cristian U.) Date: Sep 15, 19:57 From: Troy Mockenhaupt <troymock88@yahoo.com>

In response to your last question about how can TDD be effective in languages without integrated unit tests. My opinion would be that just because a language doesnt have integrated unit tests, doesn't mean that TDD can't be effective because the general idea of Test first development can still be helpful in reducing the amount of defects. It would more than likely be less effective at removing defects and also cost a lot more to develop good tests, but still helpful.

re: re: re: Question 2 Re: re: re: Question 2 (Troy Mockenhaupt) Date: Sep 16, 21:18 From: Cristian U. <christianurs@yahoo.com>

I agree with you: TDD could be an efficient method even with no integrated unit test. However, we should take in consideration some other cases. For example, how we will be able to apply TDD to our entire huge application which we are developing, if the programming language doesn't have an integrated unit test? I think it will not be the most efficient method and it will take a really long time until our program will be done.

re: Question 2 Re: Question 2 (Prof. Lingard) Date: Sep 13, 14:10 From: The B00giem0n <benjamin.riveira.832@csun.edu>

“With TDD, the programmer writes the unit tests prior to the code under test. As a result, the programmer can immediately execute the tests after they are written.” • This statement is somewhat unclear; what are the “they” the authors are referring to, the unit tests or code under test? How can tests be executed if the code to test hasn’t been written yet? “TDD has emerged within a particular set of process models.” • Which set of process models? “Some individual software developers and smaller teams apply even finer-grained models such as the personal software process or the collaborative software process.” • What are the “personal software” and “collaborative software” processes?

re: re: Question 2 Re: re: Question 2 (The B00giem0n) Date: Sep 15, 20:40 From: Peter Guy

The wording in that phrase is awkward, but I believe the idea the authors are trying to communicate is that with TDD, testing the code typically happens much sooner than with a "traditional" approach, resulting in the code, and the test, being fresher in the minds of the programmer, resulting in higher efficiency. TDD is most popular in agile methodologies. I didn't know what the "personal software process" or "collaborative software process" were, either, but Wikipedia has a definition of the personal software process (http://en.wikipedia.org/wiki/Personal_Software_Process), and you can find a discussion of the collaborative software process here: http://www.cs.utexas.edu/users/csed/doc_consortium/DC99/williams-abstract.html

re: re: re: Question 2 Re: re: re: Question 2 (Peter Guy) Date: Sep 16, 15:42 From: Eric D

PSP is all about lowering defects, both by planning/designing code before its written, and then carefully investigating each defect written to understand how to not make the same mistake again. I haven't studied PSP in conjunction with TDD but they seem compatible. PSP seems a bit more effort than TDD, though.

re: re: Question 2 Re: re: Question 2 (The B00giem0n) Date: Sep 15, 21:52 From: The B00giem0n <benjamin.riveira.832@csun.edu>

Ah, thank you Peter! There were quite a few passages in the book that seemed somewhat vague in meaning; but of course, this might be attributable to the fact that my reading was done between the hours of 2400 and 0200. I'll check out the wikipedia definitions of those software processes.

re: Question 2 Re: Question 2 (Prof. Lingard) Date: Sep 14, 10:13 From: win <win.phyoe.58@csun.edu>

In the article, “TDD produces a set of automated unit tests that provide some side effects in the development process.” 1) What are some side effects of automated unit test in TDD? “TDD does this in an extreme way: always writing test before code, making tests as small as possible, and never letting code degrade” 1) Can we apply TDD in integration testing? If so, how can we apply TDD in integration testing? How does it differ from unit testing? Since “TDD developed within the context of iterative, incremental ad evolutionary models”, why does the article claim that “the highly disciplined practice of TDD and the simple, lightweight nature of agile processes give rise to an interesting conflict”?

re: re: Question 2 Re: re: Question 2 (win) Date: Sep 22, 18:50 From: David H

I would think that when you write test cases in TDD that you can separate test cases that you want to perform for unit tests and the test cases you want to perform for the integration tests. Because as you write the test cases for TDD, you should know what you want each unit to do and what all the units should do once they are integrated with each other.

re: Question 2 Re: Question 2 (Prof. Lingard) Date: Sep 15, 16:45 From: Edfan T

1. As the article states, the automated tests are written before the actual coding, but how they actually write the tests before the coding on where most programmers make mistakes at and since they do not know what the structure of the code going to be? 2. To what extend of difficulty does a unit need an automated test? Does a unit that only contains additions and subtractions (assuming the programmers set all the values to what they desire) need a test?

re: re: Question 2 Re: re: Question 2 (Edfan T) Date: Sep 23, 16:19 From: Alireza B. Shad <alireza.shad@csun.edu>

good points Edfan. I think the unit test becomes the actual code after refactoring. TDD is a method of writting codes to check for cases that may occur. if the test-code works properly then the programmer needs to refactor and clean the code to use it as an actual code of the program.

re: Question 2 Re: Question 2 (Prof. Lingard) Date: Sep 15, 19:14 From: Troy Mockenhaupt <troymock88@yahoo.com>

What i'm a little confused on comes from this part of the paper "In addition to testing, TDD involves writing automated tests of a program’s individual units. A unit is the smallest possible testable software component."... Im not sure i understand the difference between testing and automated testing.

re: re: Question 2 Re: re: Question 2 (Troy Mockenhaupt) Date: Sep 15, 21:13 From: The B00giem0n <benjamin.riveira.832@csun.edu>

Hi Troy, The testing they're talking about are manual tests, carried out by a person (a programmer or QA person). Manual tests involve stuff that would be difficult for a computer to do, like clicking each button in a GUI and verifying that each button does what it's supposed to do. I worked, for a time, as a QA software tester with Optical Research Associates and shortly before a version of our software was released, I would have to manually execute a 3-ring binder full of acceptance tests--stuff like stepping through the entire installation process and verifying the correctness of every window and prompt. Automated test cases are just that; they're test cases stored on and executed by a server computer. At ORA, we had five servers which would run tests very similar to the "triangle" test cases Professor Lingard had us generate for Individual Homework #1. Every night, these servers would execute hundreds of these "Set input A = to a number, Set input B = to another number, then verify the result" test cases on our nightly build. Each server would keep a graph and log of the test cases, so we could identify which test case, or group of test cases failed.

re: Question 2 Re: Question 2 (Prof. Lingard) Date: Sep 15, 22:31 From: Martin

I thought the paper was a very good overview of TDD from an academic point of view. I wish the paper also included some more hands-on experiences with TDD, especially in formal production products. One area in particular is that is unclear is the statement that “…requirements do not necessarily imply formal requirements.” I have never been on a project where the customer would allow development to progress unless there were some formal requirements. Even for a quick prototype, the customer wants a clear set of requirements so they know what will be delivered and how long it will take.

re: re: Question 2 Re: re: Question 2 (Martin) Date: Sep 16, 22:06 From: Arastu Shah

Yes Martin,I agree with you on this. There is a mention of requirements in terms of something in the head of the developer.But then this will be completely risky. I,as a customer,would like to have the requirements on paper so that I am assured that I understand what will be delivered to me. This has not been explained much in the paper and so is unclear. There is rarely a project nowadays which has just 1 developer working on it.In today's projects,you need to have atleast 2-3 developers to take care of the different tasks of designing,coding and then giving the nice look to the UI taking the help of a graphic designer.All this needs better communication in written rather than something said verbally.

re: re: re: Question 2 Re: re: re: Question 2 (Arastu Shah) Date: Sep 19, 11:15 From: Peter Guy

Something the paper didn't elaborate on, but that is an integral part of TDD, and, in fact, agile methodologies in general, is that the customer works very closely with the programming team. I think the term that's used is that the customer is "on site." This approach requires a different kind of commitment from the customer than prescriptive approaches. With prescriptive methodologies, the design and requirements process is often asynchronous: the customer and the developers/designers can often work on their assigned tasks (writing designs, reviewing designs, etc...) w/out involving their counterparts. However, with agile processes, often the best way to work design and implementation is to have the customer and the developers/designers working together. With this approach, anything that's "in the head of the developer" is quickly communicated to the customer. And not just communicated, but also demonstrated. And the customer can immediately approve or reject the ides.

re: re: re: re: Question 2 Re: re: re: re: Question 2 (Peter Guy) Date: Sep 27, 18:39 From: Martin

Excellent point. I need to think about the customer being part of the team and having a say in what is acceptable. That is a very difficult point of view to project since the majority of the time the customer is not 100% a part of all decisions, even in a so-called Agile development.

re: re: Question 2 Re: re: Question 2 (Martin) Date: Sep 20, 22:58 From: Eduardo Borjas <epb55720@csun.edu>

There are plenty of environments where requirements are not clear from the start. One of the principal reasons why software projects fail (especially large ones) is due to the fact that the requirements were wrong or simply not enough. Since this happens methodologies like agile development have sprung up to help with the issue of requirements not being fully realized (or added later in the process) before work commences. Another thing to consider is that not all projects have a clear customer. Many projects start from a brand new technology where things are changing on a daily basis. For example any new standard that is going to come out (think 802.11n) changes quite a bit until it is standardized. As a developer you will NOT know everything that is expected of the product, although you must push forward with development since time to market will be vital for new technologies.

re: Question 2 Re: Question 2 (Prof. Lingard) Date: Sep 15, 23:45 From: Anusha <anusha_nataraj@yahoo.com>

The points mentioned below in the paper are unclear:- 1) How does TDD effect software extensibility, reusability and maintainability? 2) What are the effects of combining TDD with other practices such as pair programming and code inspection? 3) How does TDD compare to test-last approach that fix the design ahead of time, as well as iterative test-last methods that build emergent design?

re: re: Question 2 Re: re: Question 2 (Anusha) Date: Sep 23, 23:40 From: Nikolas Terani

1. I think TDD affects extensability, reusability, and maintainability with a positive outcome. TDD affords a more expansive test coverage. This alone should make the code more maintainable in the sense that you are likely to find less errors after release. Additionally, the tracing of those errors might be more manageable due to the automated test suites that are still present after release. I also think that TDD helps with reusability because you are building the code from a singular standpoint; to pass a test. This should create more modular code that leads to better extendability and reusability. Additionally, the fact that refractoring is used in conjunction with TDD allows aids all three of these characteristics of the product.

re: Question 2 Re: Question 2 (Prof. Lingard) Date: Sep 16, 01:48 From: David H

2.The author states on pg.44 that “TDD assumes that software design is incomplete.” However on pg. 43, the author writes “TDD enables design through refactoring.” So my question is, how much design is usually done prior to refactoring and how much is done after it. Or does it even matter?

re: Question 2 Re: Question 2 (Prof. Lingard) Date: Sep 16, 14:05 From: Jerry

I would like to know more about the side effects in the development process produced by the automated tests. The other thing that I wish a better explanation is how TDD is integrated since pre-written tests before coding can be dangerous if there is no prior knowledge or a basic understanding of what the code is supposed to be.

re: re: Question 2 Re: re: Question 2 (Jerry) Date: Sep 16, 15:55 From: Jack Weaver <weaver.jack@gmail.com>

This can sometimes be a problem: your not 100% certain of the code requirements. Thats why it's important to know what responsibilities and collaborators exist to the code you are developing. Then at that point it's easier to make the design decisions, and then run a TDD approach. Your right in being concerned though, if your not sure what the code is suppose to be (do) then writing test cases wont help. So the requirements have to be (somewhat) well defined.

re: Question 2 Re: Question 2 (Prof. Lingard) Date: Sep 16, 14:07 From: Harvey Alexian <xharvey-ax@sbcglobal.net>

I’m not sure I quite understood TDD in its full details , although I’m somewhat clear about the general idea of TDD. However the part I’m still not clear about is how can TDD increase the productivity of a programmer ? because it seems to me , this approach always requires more coding for generating test cases compare with common code first –test later methodologies.

re: re: Question 2 Re: re: Question 2 (Harvey Alexian) Date: Sep 20, 15:32 From: Christian U.

I believe that in a long term, a project done using TDD will have less errors and therefore, the company will spend less money in fixing bugs after the product has been released. So, the programmer can be considered as being more productive...

re: re: re: Question 2 Re: re: re: Question 2 (Christian U.) Date: Sep 23, 12:54 From: Harvey Alexian <xharvey-ax@sbcglobal.net>

According to survey data in the article , not always TDD increasing the productivity. I think there is a optimum range for the size of a software program that can be suitable for this method, because for example the overhead for very small projects would be too large for allowing us to implement this method.

re: Question 2 Re: Question 2 (Prof. Lingard) Date: Sep 16, 14:09 From: Alireza B. Shad <alireza.shad@csun.edu>

2. One of the issues that I didn’t understand and need more explanation is that, why TDD doesn’t fit in every situation. If this tactic is about testing before the actual code of a program, then why wouldn’t be suitable for the entire project or for every project?

re: re: Question 2 Re: re: Question 2 (Alireza B. Shad) Date: Sep 20, 23:53 From: Eduardo Borjas <epb55720@csun.edu>

Obviously designing everything is important but it is a mater of scale. Do you really have to spell out requirements, design and test every unit piece of code? Now I am with you that you need to build requirements and design every unit BUT do you need to test it too? If a coder has written a similar piece of code 100 times before and had zero bugs, do they still need to write a test for it? When testing you can't test everything. That is one of the things Professor Lingard has said in his lectures. The same SHOULD apply to TDD. Is it worth testing everything? Or should we look to target certain areas where it is worth it (like in software inspections) and leave the rest to other processes like validation. This way there is an obvious cost-benefit to TDD without going overboard.

Answer 2 Re: Question 2 (Prof. Lingard) Date: Sep 16, 14:13 From: Arastu Shah <arastujshah@gmail.com>

“Developer must now maintain both the production code and the automated tests.” I agree with the author here about the fact that it increases the work of a developer in regards to time, efforts and documentation. I didn’t quite understand what the author is trying to point out in these sentences. A. “If the increments require modifying a significant amount of overlapping software, we can say that our methodology is more iterative in nature. Specifically, for project P consisting of code C and iterations I=&#61651;i = 1 N Ii, if Ci is the code affected by iteration Ii, and if project P is iterative, then Ci &#8745;&#61472;Ci + 1 &#8800;&#61472;&#61640;&#61472;for most i such that 1 < i < N. B. “As Beck states,XP takes the known best practices and “turns the knobs all the way up to ten.”” C. “Always writing tests before code, making tests as small as possible, and never letting code degrade.” Why to make smaller tests??No explanation for this.

re: Answer 2 Re: Answer 2 (Arastu Shah) Date: Sep 16, 15:37 From: Eric D

A. Each iteration will add new code and or affect different parts of previous code. B. XP uses best-of-breed approaches that synergize with each other. However, since parts of XP methodology depend on each other, not following one part can have large negative consequences, e.g. working past a 40 hour week consistently. see http://www.ibm.com/developerworks/library/j-xp/ C. “Always writing tests before code, making tests as small as possible, and never letting code degrade.” By testing the smallest amount possible, you isolate test failures to a small chunk of code. Never letting code degrade means you keep running the tests for each version so you know that tested functionality is not changed.

re: re: Answer 2 Re: re: Answer 2 (Eric D) Date: Sep 22, 17:16 From: Arastu Shah <arastujshah@gmail.com>

thanks eric That was very helpful

re: Question 2 Re: Question 2 (Prof. Lingard) Date: Sep 16, 15:27 From: Jack Weaver <weaver.jack@gmail.com>

I believe the paper outlines the essential qualities of TDD. After having practiced it in industry, I can relate to a lot of the topics the paper brings up. TDD is no silver bullet, but it is another powerful tool which can be used to write complex software. It also "keeps you on your toes" when there exist test cases already written that you yourself did not write, because often times other people will think of problems differently, and their different vantage point allows for a wider test suite, which results in stronger code. A good primer (and a reference book used where I worked at) is "Test Driven: TDD and Acceptance TDD for Java Developers" And the article seems to capture a lot about what is written in that book as well.

re: Question 2 Re: Question 2 (Prof. Lingard) Date: Sep 16, 16:19 From: Ricardo Miron

The article states that TDD lowers defect density, but does not mention how it affects time to market. Does TDD increase or decrease a projects time to market?

re: re: Question 2 Re: re: Question 2 (Ricardo Miron) Date: Sep 20, 22:40 From: Eduardo Borjas <epb55720@csun.edu>

I think you pose an excellent question. If the quality of the TDD process is high in not introducing software defects then by the time the code gets to traditional validation testing, it may pass without needing any additional rounds of testing. In general the number of test cases should be lower anyway. If this happens then your time to market may be better then using a traditional model. I can speak from experience that not using TDD or any sort of concurrent testing (during development) can lead to two or three delays in releasing a product. Typically each delay in my experience was about a month. Now if TDD added an extra month to development but caused no additional rounds of testing, then it is DEFINITELY worth it. It all depends on the metrics found before and after TDD was implemented to determine what is the best way to approach this. If the TDD quality is low and bugs are still being found at the same rate during validation, then this needs to be looked at. Either TDD needs to be removed altogether or training developers to be better at TDD.

re: Question 2 Re: Question 2 (Prof. Lingard) Date: Sep 16, 18:40 From: Anna Brjezovskaia <Anna.Brjezovskaia.509@csun.edu>

I don’t understand what design decisions are meant by saying that TDD drives software design

re: re: Question 2 (Anna) Re: re: Question 2 (Anna Brjezovskaia) Date: Sep 22, 14:36 From: Anusha <anusha_nataraj@yahoo.com>

Regarding your question : "What design decisions are meant by saying that TDD drives software design?" Design decisions like software’s interface (e.g. parameters, return types, and exceptions thrown),software’s behavior (e.g. expected results given certain inputs) are influenced by TDD.

re: re: Question 2 Re: re: Question 2 (Anna Brjezovskaia) Date: Sep 23, 16:07 From: Alireza B. Shad <alireza.shad@csun.edu>

there is always many ways to solve a particular problem. TDD derives software design in a way that when testing the code a programmer may come up with various codes that does the same task, which would affect and drive the design of a product.

re: re: re: Question 2 Re: re: re: Question 2 (Alireza B. Shad) Date: Sep 30, 18:38 From: Velimir

TDD let the programmer design a specific pattern for testing that has to be implemented throughout the software. Based on this pattern the design will be clearer to use among the programs and the final product in terms of code will be more organized and structured.

re: Question 2 Re: Question 2 (Prof. Lingard) Date: Sep 16, 22:53 From: Nick Terani

1.One of the main questions that I have is how can it be implemented? For example, what types of applications frequently implement TDD. The author states that it is used within the context of Object Oriented Programming but how about some examples of its implementation? It would have been helpful to understand the primary concepts of how it aids in analysis, design, and programming decisions through illustrative examples. Specifically I would have liked to have seen some examples on how it directly can affect interface decisions, requirements elicitation, and various programming choices. 2.How are requirements elicited in a process that implements TDD? Do the test cases truly determine requirements or are they merely a way to refine them?

re: Question 2 Re: Question 2 (Prof. Lingard) Date: Sep 22, 10:04 From: Omer

None

re: Question 2 Re: Question 2 (Prof. Lingard) Date: Sep 24, 09:52 From: Velimir

I don’t understand how are the test cases created ? How are the test cases tested? What should be the relationship between the test and the unit tested, in terms of logical , input and execution?

re: Question 2 Re: Question 2 (Prof. Lingard) Date: Oct 07, 17:59 From: Sphoorti Madugula

1. Is writing test cases in TDD based on the specifications the same as coming up with the algorithms for the code? Are these two processes related, and if they are, how are they similar? 2. Would writing test cases beforehand cause problems if and when the specifications are unclear or the customer’s requirements change after the test cases and code was written? What if the test cases had to be discarded completely because the customer changed his mind? Wouldn’t it be a waste of time and money? If the developers started coding directly rather than spending time to come up with the automated test cases, and then, writing the code, wouldn’t it save them the time they spent on writing the test cases? (So, technically, the time they spent on writing the code would be of a waste, as opposed to the other case, where they’d have spent time to write the test cases, and THEN write the code…) 3. In fields where creativity is a concern, if the developer does come up with test cases that fulfill the code as far as functionality goes, but doesn’t focus too much on the overall ‘look’ or appearance of it, how would TDD prove effective as far as coming up with a product that is bug-free, but unattractive to customers goes? For example, as an intern at MySpace, I see developers working on themes on the profile and home pages in MySpace. To me, it seems as if they don’t really care about little details, which I, as a user, would very likely pay attention to, or would expect or want. These details, to be specific, include things such as: i. Text within modules spilling out, instead of getting wrapped to the next line so as to not cross the module boundary. ii. Certain modules formatted differently (looking out of place) even if they are supposed to follow the ‘theme’ specified by the user. iii. Font styles or sizes being off or unsightly. iv. Alignment within the modules. v. Certain objects having backgrounds with a gradient, and others missing that very feature even if they’re supposed to be the same way. vi. Variations of the ‘look’ of the page with the browser or the operating system being used. These things make a huge difference not only to me, but also to the millions of users who literally pour out their personality and creativity into making their profile. However, for the developer(s) who write code for the themes, these are ‘minute’ or ‘insignificant’ things. “As long as the code doesn’t throw an exception, we’re good” is what they feel most of the time. My question is, if they’re allowed to come up with the test cases for a product where such things are of concern, would it not be inefficient? If the tester, like me, is to write the test cases or manually test the code they’ve written, wouldn’t it help focus on items which are trivial to the programmers, but important to the user? 4. The above leads me to this question --- how can automated test cases be written for specifications which involve items like formatting or images or basically the graphical part of the user interface. Wouldn’t it have to be done manually? And if it is done manually who would be in charge of that? The testers or the developers? As far as TDD goes, how can writing manual test cases be incorporated into the process, seeing as to how it requires writing automated test cases? Wouldn’t writing a bunch of different types of test cases waste more time? 5. What would the point of having automated test cases be in places where the nature of the methodology is less iterative and more unique? 6. What is the role of the product manager or business analyst in TDD be? Would they be involved at all? What would be expected of them? Would designing the product be completely in the hands of the developers?

Question 3 Date: Sep 03, 12:18 From: Prof. Lingard

Do you agree with all the positions and claims represented in this paper? Describe any areas of disagreement you have.

re: Question 3 Re: Question 3 (Prof. Lingard) Date: Sep 09, 20:18 From: Eric D

No. I think that there need to be more tools written to support TDD, especially in non-Eclipse IDEs. Programmers live in their IDEs, so xUnit is of little use to Visual Studio users.

re: re: Question 3 Re: re: Question 3 (Eric D) Date: Sep 13, 14:23 From: The B00giem0n <benjamin.riveira.832@csun.edu>

Eric, Many tools are available for unit testing in Visual Studio. Here are just a few: The NUnit framework is written entirely in C# and is available at http://www.nunit.org I have some experience with MbUnit which is a test framework that can be coupled with the Gallio Automation Platform. Gallio, which includes MbUnit, is available at http://www.gallio.org/. And last, but not least, the Microsoft Visual Studio Team System integrates some very nice unit testing tools into the IDE.

re: re: Question 3 Re: re: Question 3 (Eric D) Date: Sep 16, 22:11 From: Arastu Shah

The paper leads to a conclusion that the tools mostly support Java programming and other open source languages.This makes me think about the Microsoft languages as well and other mobile languages which should have specific tools related to TDD. I was in favor of what the author writes in the paper but now I have this opinion after reading your thoughts Eric.You have pointed it out well. There needs to be more tools for different kinds of languages.

re: Question 3 Re: Question 3 (Prof. Lingard) Date: Sep 11, 13:29 From: Eduardo Borjas <eduardo.p.borjas@csun.edu>

Agreements Fundamentally I agree with many components of the feature. Breaking down test-driven development we have the following: o Automation – I completely agree with anything that can be automated, especially when combining multiple tests into a single click test. This way there is no little need for human interaction (fewer resources) with testing. o Unit Tests – I partially agree that unit testing should be done, the part I disagree with is mentioned later. Being able to have unit tests on major portions of the program is a huge benefit especially when it comes to regression testing. Being able to test a chunk of the code efficiently after making any change is a huge benefit. o Refactoring – The basic idea that the code writer writes code to pass their unit test first and then goes back (refactor) to clean up the code is definitely a neat idea in high risk or complicated portions of the program. This cuts down on the time finding possible errors (not syntax or compilation issues) of the portion of code. o Requirements/Design Before Coding – Forcing the developer to think about the requirements and testing before developing is definitely a great concept. It shuts down developers who go directly into coding based off general ideas of what they need to do and then worry about testing later. Worrying about the testing first forces them to consider the main points of coding, all alternatives and places where testers would try to find cracks in their code. Disagreement #1 It seems that TTD wants to enforce that every unit of code in the system gets the utmost attention in testing. I don’t think it is reasonable to expect that every unit of code be tested especially if we are looking at code being reused or code that is generally considered harmless (something an experienced software engineer may have written 100 times before without having one single bug). The attention to detail can lead to situations as stated in the article below. “In this ThoughtWorks project, developers used16,000 lines of automated unit tests on 21,000 lines of production code.” Basically doubling the code size of a project due to testing seems to be overkill. Some attention has to be paid to the overall software (top down approach) as opposed to focusing on just the bottom up approach at first. I think the better solution is to use TTD in code areas that are medium to high risk, are constantly in use or where code may be in constant flux. This way full testing can be done on those parts of the code that definitely warrant the attention. TTD in conjunction with traditional SQA testing can definitely be an asset. Focusing so many resources on just TTD may lead to validation resources being dwindled to the point where more bugs will pop up since system level testing is being ignored. Disagreement #2 It is a basic rule of thumb that programmers do not make the best testers. One of the points of TTD is that developers do all of the unit testing. If that is the case, management may decide that system level and integration level testing can be scaled back. Which when combined with my first sentence means that we could be overlooking at lot of things that could be considered defects. I think that while unit testing is important it is still vital that traditional SQA is used in testing. As long as there is a good level of SQA remaining, then the fusion of TTD and SQA could be a beneficial relationship.

re: re: Question 3 Re: re: Question 3 (Eduardo Borjas) Date: Sep 12, 16:07 From: Peter Guy

Eduardo, I think you're focusing too much on testing. TDD isn't really at all about testing, it's about analysis, design and implementation. I do agree that TDD can potentially double the amount of code that's written. I think this could be a problem if TDD is not approached correctly.

re: re: re: Question 3 Re: re: re: Question 3 (Peter Guy) Date: Sep 20, 23:58 From: Eduardo Borjas <epb55720@csun.edu>

I think it is all great that every unit is analyzed, designed and implemented. Yet according to the article testing is also required. It is the testing portion that is making me wonder the effectiveness of the approach. One of the things Professor Lingard said in his first lectures was that you can't test everything. You need to find the right amount of testing that is cost effective. I think TDD should be used just how software inspections are used, on risky or high functioning code (among other reasons). If a developer knows going into a unit piece of code exactly what needs to be done because he has done it 100 times before without ever introducing single bug, why should he bother writing test cases for it?

re: re: Question 3 Re: re: Question 3 (Eduardo Borjas) Date: Sep 12, 21:40 From: Anthony Arnold

I disagree that "coders" necessarily make bad testers. I think the more important part to focus on is the independence between the implementer and the tester. I agree with you complete on that point.

re: re: re: Question 3 Re: re: re: Question 3 (Anthony Arnold) Date: Sep 21, 00:03 From: Eduardo Borjas <epb55720@csun.edu>

Not all coders make bad testers, I agree with you on that point. Certainly a large amount of them would make good testers of OTHER people's code. There are many reasons why people hand off their work to others to verify/validate (i.e. rough drafts of papers, certification processes, etc). I think the key point is that people who are trained at testing are more likely to find problems. For example in our first homework assignment only two people got every type of test case correctly. The professor stated that people usually only get 7/8 right of the 13.

re: re: Question 3 Re: re: Question 3 (Eduardo Borjas) Date: Sep 15, 19:52 From: Troy Mockenhaupt <troymock88@yahoo.com>

I would agree with what Peter said regarding this post. I think that TDD is only going to greatly increase the amount of code if the test cases are poorly designed, and if you think about it, more code but less defects will end up with happier customers.

re: Question 3 Re: Question 3 (Prof. Lingard) Date: Sep 12, 14:58 From: Peter Guy

The idea of designing by writing a consumer for your code first appeals to me because it keeps development focused and quickly highlights design flaws. Once the consumer is written, it can stick around and be used at almost any point in the development lifecycle thereafter to verify that the code still behaves the way it is supposed to. I think the concept of orthogonality is important, and I see how TDD is instrumental in producing orthogonal code. However, writing so many tests can effectively double the amount of code a developer is responsible for. If the TDD approach simplifies the whole development lifecycle, then this isn't necessarily a bad thing, but it seems to me that if TDD is approached even a little bit wrongly, it could lead to lots of frustrating overhead. It may be tempting to view TDD as a panacea, but that way lies madness. Unless the whole development process can support TDD, it will end up increasing the burden on the programmer without adding any benefit. TDD is all about design, so it would have to be incorporated into the programming lifecycle early. It also cannot exist on its own, but must be used together with other programming concepts, especially the single responsibility principle. This isn't a disagreement with the article, per se, but I think the name is misleading. It causes one to focus on the test - to immediately assume that TDD is all about testing and QA, when it's not. "Tests" are written at the beginning of the design process, and their goal is to aid in the design, specification and implementation of code, not to aid in the testing of code that has already been written. A better name might be Consumer Driven Development, because what the developer is really doing is writing a consumer for his code before writing the code, not so much writing a test. The ability to use this consumer to ensure the proper functioning of the unit of code later in the development lifecycle is certainly useful, but the real goal of writing the "test" is to clarify how you're going to go about writing the implementation.

re: re: Question 3 Re: re: Question 3 (Peter Guy) Date: Sep 20, 23:09 From: Eduardo Borjas <epb55720@csun.edu>

I think the keyword here is overhead. How much does TDD actually improve software quality and what are the costs associated with it. The article points to a pretty high percentage (up to 50% reduction in defect density). Now that number is good but what if the money used to do this (obviously it will take a developer a longer time to write code when TDD is involved) could be used to have better system testing tools (back end) or to use other software quality process initiatives (front end) like software inspections and formal reviews? Does every piece of code really need to be thought out, designed, implemented and tested? I think the key point here is "tested", the others are quite clear that we need to do them but must everything be tested or could key pieces of code (high risk, high functional, etc) be tested while other things (printf statements, basic user input, etc) can be ignored since their likelihood of failing is low for an experienced developer.

re: Question 3 Re: Question 3 (Prof. Lingard) Date: Sep 12, 21:37 From: Anthony Arnold

I think that TDD is partly a naming game. By writing unit tests, what the developer is really doing is kind of a high level design of his code. The only real difference is that the design is "executable". The real distinction here is between writing "test cases" (i.e. requirements) and "test procedures" that implement the test cases. However I do think that the fact that the design is executable is a huge plus, because it does allow the developer to tweak the detail of the implementation while remaining compliant with the high level design of the unit. An area that really bugs me is the fact that TDD is defined such that it is the same developer who writes the unit tests for code and the code itself. I think it is important that an independent tester be responsible for verifying functionality and compliance to requirement. It may not be necessary for all requirements, but there are certainly always a "critical" subset of requirements that absolutely must be met, and be met correctly. Independence is the best way to achieve that goal.

re: re: Question 3 Re: re: Question 3 (Anthony Arnold) Date: Sep 15, 22:52 From: Martin

In reply to your second point: In my minimal understanding and experience of TDD, I believe the unit tests are only to ensure that the code performs the required features. Ideally, once all unit tests have passed the program/project is bug-free (right!). You still need a V&V team to bang on the product and find the faults that us developers have overlooked or faults in which test cases were never written for.

re: re: re: Question 3 Re: re: re: Question 3 (Martin) Date: Sep 16, 21:34 From: Anthony Arnold

True, within the scope of a larger software development process, a more traditional V&V could also take place... just seems like there would be some rework if they did unit testing again. Maybe the separate V&V effort would focus more on integration testing...

re: re: Question 3 Re: re: Question 3 (Anthony Arnold) Date: Sep 23, 15:49 From: Jerry

The point of writing test cases for TDD isn’t really to “test” in the manner spoken here. I think of it as more of a way to assist the coding that is to be done. Knowing what test cases lies ahead will make the program adapt to solve/patch any problems or abnormalities.

re: Question 3 Re: Question 3 (Prof. Lingard) Date: Sep 13, 14:25 From: Cristian U. <christianurs@yahoo.com>

I agree with some of the claims and positions but I also have some disagreement: Some of Agreement:   * TDD could help in error reduction and quality improvement   * Automatic testing and refactoring is a good idea   * Unit testing tools like JUnit for Java is very helpful   * TDD will decrease the productivity of developers Disagreement:   * I don't agree with the the main idea that design should be after testing and coding   * I don't believe that a programmers will refactor that much once the code works properly   * I believe is a mistake to have XP and agile programing introducing software engineering to undergraduates   * The research study of North Carolina State University used just a few software companies to test the profitability of TDD approach. They should take in discussion a considerable amount of companies in order to give a more accurate statistic.

re: Question 3 Re: Question 3 (Prof. Lingard) Date: Sep 13, 14:26 From: The B00giem0n <benjamin.riveira.832@csun.edu>

Throughout most of the article, I felt that the authors were pushing the subtext “TDD works miracles for everyone” and I strongly disagree with this philosophy. However, in the last three sections, the authors reveal their true motive is to suggest that TDD should be integrated into undergraduate curriculum, and that more research needs to be done on the impact of TDD in the industry. I wholeheartedly agree with both of these points.

re: Question 3 Re: Question 3 (Prof. Lingard) Date: Sep 14, 10:15 From: win <win.phyoe.58@csun.edu>

According to the article, the potential adopters have a concern regarding time and cost of writing and maintaining unit tests, I only agree on a concern regarding cost since TDD requires unit test case for every single small unit of every phase before writing code and need to maintain all of these test cases for future, the overheard cost for maintaining and producing the code can be doubled.   However, I don’t agree a concern regarding time since TDD involves a large numbers of test cases for every single component; it can decrease time to concentrate on inspection to find defects because code has already passed unit tests.

re: Question 3 Re: Question 3 (Prof. Lingard) Date: Sep 15, 19:33 From: Troy Mockenhaupt <troymock88@yahoo.com>

What i disagree with is when the author states near the end of the paper that even if there is a decline in XP development, that TDD will still persist. I think that TDD will be best suited for integration with XP techniques and therefore will decline in popularity if XP declines in popularity.

re: re: Question 3 Re: re: Question 3 (Troy Mockenhaupt) Date: Sep 15, 20:26 From: Peter Guy

Actually, Troy, while I agree that TDD is only a piece of the programming effort, I think it fits in well with many different program lifecycles. Granted, it's mostly seen in agile methodologies, and it seems like a natural fit there, but it can have its place in prescriptive approaches, too. As an example, today I was programming a module for another programmer. He and I had discussed what this module needed to do, and we had agreed on a design. As I got into it, though, I was having trouble with the implementation. It wasn't a particularly difficult piece of code to write, but I was getting hung up in the "what-ifs": "what if he tweaks the inputs like so?" "What if the data he's using isn't exactly right?", etc..., so I stopped writing the implementation and wrote a dummy consumer for it. I set up the inputs in the ways I was worried about - and a couple of other ways that came to mind at the time - then checked the output for correctness. After that, coding the implementation was a snap. While I was implementing, I ran the tests to see it break, then work, then break again as I changed things. Then, when I was done, I had these test I could run against it at any time, and that he could use to check my module, and as examples to see how to use the module, too. So these test cases I created were not just tests, but were also: - design - implementation catalyst - examples - documentation - validation checks My company doesn't use an agile program lifecycle, but a prescriptive one - a kind of modified waterfall. And yet I was able to use TDD to make my life easier today. I could have written down my implementation challenges and come up with more design on paper, but that design would have had a more limited usefulness than the test cases I wrote.

re: Question 3 Re: Question 3 (Prof. Lingard) Date: Sep 15, 21:57 From: Edfan T

I don't agree: 1. Of the idea how the tests are done before the coding. 2. That the length of the unit automated test is almost the same as the actual code which I assume doubles the time required to do the whole thing. I agree: 1. That TDD has an impact of decreasing of programmers' productivity and applying it takes longer. 2. That TDD improves software quality by refactoring.

re: Question 3 Re: Question 3 (Prof. Lingard) Date: Sep 15, 22:23 From: Martin

There is one area that I am not fully convinced would be fully implemented in TDD is refactoring. Test Driven Development formally incorporates refactoring after successful testing. Refactoring is intended to improve the structure of the code without changing the external behavior that is, it should still pass the same set of tests. It is very common for developers to be under the pressure to meeting schedules, how important would the refactoring become to the managers if the end product will not produce any immediate difference or advantage? Also, many developers are probably not ambitious enough to thoroughly refractor code that already meets the requirements.

re: re: Question 3 Re: re: Question 3 (Martin) Date: Sep 20, 23:18 From: Eduardo Borjas <epb55720@csun.edu>

I am totally on board with your opinion. There is no clear incentive to either the manager or the developer once there is a working product. Although if I were to play devil's advocate, that is only true in the short term. In the long term having better (clearer) or more structured code can make integration much better. Also when code needs to be redone due to changing requirements, having clearer code would also be much easier to alter. What needs to be looked at is the long term goal of the product, not the unit that is currently being worked on.

re: Question 3 Re: Question 3 (Prof. Lingard) Date: Sep 15, 23:47 From: Anusha <anusha_nataraj@yahoo.com>

I agree with the following points:- 1. TDD can be combined with other process models. 2. TDD requires a lot of discipline on the developer’s part. 3. TDD cannot be applied for every situation 4. Drawbacks include that developer must maintain production code and automated tests. I disagree with the following points:- 1. TDD requires delay in design decisions. 2. TDD decreases developer’s productivity.

re: re: Question 3 Re: re: Question 3 (Anusha) Date: Sep 20, 15:54 From: Cristian U.

Regarding your second disagreement, that a programmer applying TDD will not decrease his/her productivity, I believe that the time required to come up with all the tests in the initial stage will be significant. This will delay the design and therefore, you can say that the programmer's productivity has been decreased.

re: re: re: Question 3 (Cristian U.) Re: re: re: Question 3 (Cristian U.) Date: Sep 22, 14:28 From: Anusha <anusha.nataraj@yahoo.com>

TDD assumes that the software design is incomplete or it evolves as the software grows. Hence for time spent in writing test case by the programmer, he/she contemplates and decides on the design. It increases programmers clarity on the feature and how to go about implementing.Hence the programmer's productivity will not decrease.

re: re: re: Question 3 Re: re: re: Question 3 (Cristian U.) Date: Sep 23, 23:45 From: Nikolas Terani

You have to look at productivity as a whole and not on an individual basis. That is the focus must be on the process itself and not just developer output. What seems to be most important is not how much time was spent on the test case development, but did the overall cost of production and maintenance go up or down after the implementation of TDD. If it goes up then productivity went down. If it goes down then productivity went up.

re: re: Question 3 Re: re: Question 3 (Anusha) Date: Sep 30, 18:49 From: Velimir

" TDD requires delay in design decisions." I think that this occur because specific patterns and design has to be created and decided on in order to use TDD. " TDD decreases developer’s productivity." I think that this issue can be ambiguous. Some programmers might even be benefit and work faster using TDD. The fallowing reasons support my theory: 1. Doing Test Cases gives a better idea about the product. 2. When Implementing a new function the programmer doesn't have to spend much time reviewing the preceding function , but rather just test with the new function and analyze . (Note: The programmer should be familiar with the basic properties of the other functions, but not know them in depth.)

re: Question 3 Re: Question 3 (Prof. Lingard) Date: Sep 16, 01:49 From: David H

3.One of the points I disagree with is the author’s skepticism about the evidence he presents. In the studies that he sites of the coporations and institutions that used TDD, the quality effects of all either didn’t change or showed a positive quality effect. As for the productivity effect, all exepct one showed a positive outcome. From these studies, it seems pretty conclusive that using TDD is helpful.

re: re: Question 3 Re: re: Question 3 (David H) Date: Sep 16, 16:08 From: Jack Weaver <weaver.jack@gmail.com>

I agree. I felt the same way too, the author almost suggests that TDD is too new and more research on its effects need to be studied first, then presents material showing it's positive effects. I think some sections of the article don't take a strong position, but linger side to side from "unknown quantity/too new" to "produces positive effects/benefits companies". Even the evidence shown in the article support the case that TDD is helpful.

re: re: Question 3 Re: re: Question 3 (David H) Date: Sep 21, 21:31 From: Anna Brjezovskaia <Anna.Brjezovskaia.509@csun.edu>

I think we shouldn’t forget that the article is written 4 years ago in 2005, where the technique was still really new. The test first techniques came up in 1999, but they only got more common after Kent Beck rediscovered it in 2003. The examples the author of the article brings are showing the effectiveness but if you see the numbers of companies which took part in the study you will notice that it is not really representative. For that reason I think the author had to deal with the results very carefully and claim more research. I guess that there are more studies by now, and if the article was written recently the authors argumentation could be “braver”.

re: Question 3 Re: Question 3 (Prof. Lingard) Date: Sep 16, 14:06 From: Jerry

TDD is definitely useful, but I don’t know if writing test cases (often times multiples of test cases) would really benefit in every scenario since it only adds more stress to the programmers. Not only that, it may delay the schedule of development. This delay and stress may be multiplied if a sudden change in the development cycle, and now the programmers have to modify the pre-written test cases.

re: re: Question 3 Re: re: Question 3 (Jerry) Date: Sep 22, 18:56 From: David H

I don't think the point of the article was that it should be used in all scenarios. The author suggests the best use of TDD is in agile development and that people could try using TDD, but it won't necessarily be useful in all scenarios.

re: Question 3 Re: Question 3 (Prof. Lingard) Date: Sep 16, 14:12 From: Alireza B. Shad <alireza.shad@csun.edu>

3. I entirely agree with this article regarding the programmers using TDD produce higher quality codes and programs. This is primarily due to the fact that TDD provides the ability to detect defects of the code earlier. According to some studies in this article, a significant improvement in software quality and much higher programmer productivity have been achieved due to the use of TDD. The only disagreement that I can think of, with respect to this tactic, is that no matter how much testing before actual code of every function is done to detect defects of the codes, when the entire program is integrated, a manual testing is necessary to test the entire product before release. This might be due to the fact that some components of a program may behave differently when integrated with other components. Therefore, a manual testing is necessary upon completion of a project, regardless of the usage of TDD throughout the project.

re: re: Question 3 Re: re: Question 3 (Alireza B. Shad) Date: Sep 23, 13:29 From: Harvey Alexian <xharvey-ax@sbcglobal.net>

I don’t think those survey results are as impressive as you described especially when it comes to the productivity of the programmer, they either didn’t see any change or they observed negative impact on the productivity. I think TDD methodology concerns about verification and not validation.

re: Question 3 Re: Question 3 (Prof. Lingard) Date: Sep 16, 14:14 From: Arastu Shah <arastujshah@gmail.com>

Yes, I agree with all the positions and claims represented in this paper. Although I would like to add that not many examples and explanation have been given to support the reason why TDD is not that well known and followed.

re: Question 3 Re: Question 3 (Prof. Lingard) Date: Sep 16, 14:53 From: Harvey Alexian <xharvey-ax@sbcglobal.net>

I strongly disagree with author’s statement that “Much software engineering research originated in academia and then found its way into common practice”. This statement was true in 30-40 years ago , but in our time , I think the vast majority of software engineering research ,new tools, and developments are originated in industry , in particular in large software companies like Microsoft, Sun microSystems ,…that almost exclusively invent new tools and methods in the field of software engineering.

re: re: Question 3 Re: re: Question 3 (Harvey Alexian) Date: Sep 20, 23:15 From: Eduardo Borjas <epb55720@csun.edu>

I would be interested in hearing some of the research, tools and developments that industry is providing. Do you have any examples? I am more inclined to believe what you are saying but I really haven't found too many examples in industry to have a clear cut opinion on this. I also would think that there is some gray area. For example I have a colleague where I work that studied in Germany. Most of his college work was tied to industry. Basically some of the work of the company was outsourced to the college. This allowed for some practical knowledge to reach the students, but at the same time some academic principles reached industry.

re: Question 3 Re: Question 3 (Prof. Lingard) Date: Sep 16, 15:10 From: Ricardo Miron

I agree with the claim that undergraduate computer science curriculum does not place enough emphasis on software design and testing.

re: Question 3 Re: Question 3 (Prof. Lingard) Date: Sep 16, 15:34 From: Jack Weaver <weaver.jack@gmail.com>

I'm not sure if I strongly disagree with the statement the article brings up, that more research is needed on TDD, however I feel that Industry has already made the decision that a good agile approach (even on large projects) which incorporate things like TDD benefit the development process greatly. I'm sure there is room for research on the effects TDD has on the development cycle and it's benefits and drawbacks, but seeing as the article is now four years old, many current day practices incorporate a lot of TDD, and industry seems to have stuck with it for long enough to determine it's benefits on their software. If "more research is needed" in order to determine the benefits of TDD, then I would point to the many (large) corporations and industries that currently make extensive use of TDD.

re: re: Question 3 Re: re: Question 3 (Jack Weaver) Date: Sep 21, 21:10 From: Anna Brjezovskaia <Anna.Brejzovskaia.509@csun.edu>

Could you may be give some exaples on which bigger companies do use this approach. I mean I've seen/heard couple times that fragments of TDD are used. But I've never heard yet that someone uses the agile approach consequently.

re: re: re: Question 3 Re: re: re: Question 3 (Anna Brjezovskaia) Date: Sep 23, 16:57 From: Jack Weaver <weaver.jack@gmail.com>

Lockheed Martin employs some agile techniques.

re: Question 3 Re: Question 3 (Prof. Lingard) Date: Sep 16, 18:54 From: Anna Brjezovskaia <Anna.Brjezovskaia.509@csun.edu>

I do agree with the fact mention in the paper that agile tactics are not enough represented in undergraduate studies, at least according to my experience.  It was only mentioned in one of my classes yet, thereby the classical Waterfall model was discussed out carefully.   Disagreement: The paper refers to the variety and maturity of supporting Tools for different programming languages naming thereby mainly Tools from Java world. The upcoming language now is C# according to my experience there isn’t such a good assortment in C# world.

re: Question 3 Re: Question 3 (Prof. Lingard) Date: Sep 16, 23:30 From: Nick Terani

I think the author lays a solid foundation for what TDD is and what the potential benefits of it are. 1. A point of contention I have is that the author states, “Test writing is in essence deciding what the program should do which is ultimately an analysis step.” However, test writing, by my understanding, is not deciding what the program should do but verifying that the program conforms to the requirements. The requirements determine what the program should do and the tests are written to verify that the program indeed adheres to those requirements. So I think there needs to be clarification in the sense that by writing test cases before the code has been written, before the design has been finalized, before the requirements fully developed is a tool or practice that helps one discover what the requirements should be, what form the design should take, and how the code should be written. It is the act itself of doing the cases before that makes it an analysis step, but test cases in general do not seem to be an analysis step in my opinion. 2. Another point of contention is the idea that TDD works well with refractoring. It seems that the whole idea of TDD is to write test cases and then write the simplest code to pass that test. Refractoring is the process of simplifying and clarifying code, but if refractoring is necessary with TDD then is TDD really effective in the first place? The whole idea is by writing a test case you create a singular focus for the code that is being generated to pass the test. It would seem logical to me that TDD would be a method that actually works the opposite to refractoring. You build the simplest code possible to pass the test and then you add to the unit to bring further functionality or create another unit to integrate with the tested unit. If this added functionality or integration of units fails the next test you know where the problem is. So perhaps it is my lack of understanding of both TDD and refractoring but this seemed counter intuitive to me.

re: re: Question 3 Re: re: Question 3 (Nick Terani) Date: Sep 23, 13:16 From: Harvey Alexian <xharvey-ax@sbcglobal.net>

I can comment on the second part . Let’s assume you have your test case and you write the simplest code to pass the test, also let’s assume in your first attempt your code didn’t pass the test ! so here is where the notion of refactoring comes into play and whatever changes you make in your code to make it pass the test is considered refactoring

re: Question 3 Re: Question 3 (Prof. Lingard) Date: Sep 22, 10:04 From: Omer

I agree

re: Question 3 Re: Question 3 (Prof. Lingard) Date: Sep 24, 09:54 From: Velimir

I agree with the paper that TDD can greatly improve the quality of a software product and the final product can be bug free. As the paper says “it helps younger” programs to develop better code.

re: Question 3 Re: Question 3 (Prof. Lingard) Date: Sep 28, 21:54 From: Sphoorti Madugula

I think I do not really see a great advantage of writing automated test cases before writing the code. One reason why I feel this way is because coming up with test cases to test existing code is much easier and time efficient. On the contrary, coming up with test cases without having ANY idea about how the customer requirements are going to be met without a basic foundation or idea about the entire product is more difficult and time consuming. At MySpace, Agile is used, and I am not sure if TDD is implemented, but I would think that working with something that changes so often, involving users whose requirements (which are further dependant on unpredictable factors) get altered routinely, using TDD would be a waste of time. Writing automated test cases, writing code, using the automated test cases as well as manual test cases for things that mutate in the matter of weeks or months, would be wasteful. It’s probably better to go with the code, test, fix if necessary and release the product approach when it involves such frequently wavering products. The paper does not really explain how much time implementing TDD takes up when compared to approaches that don’t implement it. It would have made it clearer to see the effect TDD is if the paper had statistical data associated with a particular project done by two different companies, one that implements TDD in comparison with one that doesn’t, including measurable amounts like time and money. If the article provided better metrics or at least a clear figure, such as the ratio of: (the time used for writing the automated test cases + time used for fixing the found defects) to: (the time used to fix defects found after code is written). The former figure corresponding to a case that applies TDD and the latter to one that doesn’t employ that methodology.

Question 4 Date: Sep 03, 12:19 From: Prof. Lingard

Do you think using the software development strategy described in this paper would work at a large company developing major scientific/engineering applications? Explain why or why not.

re: Question 4 Re: Question 4 (Prof. Lingard) Date: Sep 09, 20:21 From: Eric D

Absolutely. TDD helps crystallize requirements, analysis and serves a precursor for documentation. It also helps ensure that as the program evolves it does not break functionality between versions.

re: re: Question 4 Re: re: Question 4 (Eric D) Date: Sep 11, 13:30 From: Eduardo Borjas <eduardo.p.borjas@csun.edu>

I don’t think test-driven development (when taken for its literal definition with all units of code needing to be tested) will work for larger scientific/engineering applications. TTD is closely affiliated with agile development, which isn’t meant for big projects, TTD can considerably add to the length of time to develop a product, TTD splits a developers focus into testing and writing code and TTD requires a brand new set of management initiatives. Since TTD is associated with agile software development, I don’t think TTD can work in this environment. The reason being that a major scientific/engineering application tends to have many engineers. According to Robert Wiley (Wysocki, 2009) there are typically less than 15 people in an agile project team. Agile doesn’t seem to work in these environments. Also major applications in general need to be well defined and documented. Without that it would be literally impossible to develop anything on time, with the estimated number of resources and under cost. The reality is if requirements consistently changed than any early testing could technically be invalidated (and when talking about tons of code, that would become impractical). Only if a project could be efficiently decoupled into sub projects would TTD have a change of succeeding. The project may take way longer than expected if so much time is put into TTD instead of doing a good combination of tests done at different times of the process. According to the text, “Many developers might have been thinking and coding in a test-first manner, but TDD does this in an extreme way: always writing tests before code, making tests as small as possible, and never letting code degrade“. A major application is thousands upon thousand lines of code. If there is as many lines of code for automated unit tests as there is for production code, that can lead to a significant amount of “wasted” code. Not only is the code that is going to be shipped to a customer need to be tested, but also the automated unit tests need to be tested. Developers now have to worry about writing test cases along with actual working code. The complexity of the process just makes things worse in some respects. When projects become larger and are more complex, unit testing becomes less important since there are more system and integration tests to be concerned about as well. Since TTD hasn’t been used much in industry yet, there may be a lot of training needed to get everyone up to date. Most importantly getting management involved will be a considerable task. With TTD there seems to be extra management needed in order to make sure that test quality is high, that TTD is being followed and that TTD is being done on every unit of code. Without many examples in industry, a company would have to innovate much of the process to fit its particular project management life cycle. I think a lot of thought has to be put into how to apply TTD in larger applications. I think definitely some concepts will work but applying it as a complete process will not work. Bibliography Wysocki, R. K. (2009). Effective Project Management. Indianopolis, IN, USA: Wiley Publishing.

re: re: re: Question 4 Re: re: re: Question 4 (Eduardo Borjas) Date: Sep 12, 18:56 From: Peter Guy

Agile programming does indeed seem to be best applied to small programming groups, but that's not a reason for it to fail when applied to large projects. Every large programming effort should be able to be broken down into simple units. I suppose we could compare it to an automobile manufacturing process: automobiles are large and complex, but they are still made up of many small parts. Each part has its own functionality, and each part is validated before being built into the whole. In like manner, even large programming projects are composed of lots of small "units" of code, each of which accomplishes a single objective. Every one of those units should be able to be tested individually to ensure proper functionality before being compiled into the whole program. A basic premise of agile programming is that if you cannot easily unit test your code, there is something fundamentally wrong with your design. In fact, agile programmers would argue that your statement, "When projects become larger and are more complex, unit testing becomes less important," is completely backward. They would say that the larger a project becomes, the more important the unit test is. Also, you are still approaching TDD from the perspective of testing. It is not a testing strategy, despite its unfortunate name. It is, rather, a method for determining and refining design specs, and then advising implementation of those specs.

re: re: re: Question 4 Re: re: re: Question 4 (Eduardo Borjas) Date: Sep 16, 15:46 From: Eric D.

I would agree that you would need more than solely TDD as a programming methodology, but the principles of design tests before writing code, and use unit tests to make sure code doesn't degrade are very valuable for a large scientific/engineering project. If you're doing science/engineering, code has to be right, and test-driven development is a good way both to verify solutions and deconstruct problems.

re: re: Question 4 Re: re: Question 4 (Eric D) Date: Sep 23, 15:50 From: Jerry

I agree, TDD helps make requirements and analysis easy to understand. At the same time, it makes sure the program will still function after improvements or changes being made.

re: Question 4 Re: Question 4 (Prof. Lingard) Date: Sep 11, 13:33 From: Eduardo Borjas <eduardo.p.borjas@csun.edu>

[Sorry I posted as a reply to the first posting for question #4, it should be here instead] I don’t think test-driven development (when taken for its literal definition with all units of code needing to be tested) will work for larger scientific/engineering applications. TTD is closely affiliated with agile development, which isn’t meant for big projects, TTD can considerably add to the length of time to develop a product, TTD splits a developers focus into testing and writing code and TTD requires a brand new set of management initiatives. Since TTD is associated with agile software development, I don’t think TTD can work in this environment. The reason being that a major scientific/engineering application tends to have many engineers. According to Robert Wiley (Wysocki, 2009) there are typically less than 15 people in an agile project team. Agile doesn’t seem to work in these environments. Also major applications in general need to be well defined and documented. Without that it would be literally impossible to develop anything on time, with the estimated number of resources and under cost. The reality is if requirements consistently changed than any early testing could technically be invalidated (and when talking about tons of code, that would become impractical). Only if a project could be efficiently decoupled into sub projects would TTD have a change of succeeding. The project may take way longer than expected if so much time is put into TTD instead of doing a good combination of tests done at different times of the process. According to the text, “Many developers might have been thinking and coding in a test-first manner, but TDD does this in an extreme way: always writing tests before code, making tests as small as possible, and never letting code degrade“. A major application is thousands upon thousand lines of code. If there is as many lines of code for automated unit tests as there is for production code, that can lead to a significant amount of “wasted” code. Not only is the code that is going to be shipped to a customer need to be tested, but also the automated unit tests need to be tested. Developers now have to worry about writing test cases along with actual working code. The complexity of the process just makes things worse in some respects. When projects become larger and are more complex, unit testing becomes less important since there are more system and integration tests to be concerned about as well. Since TTD hasn’t been used much in industry yet, there may be a lot of training needed to get everyone up to date. Most importantly getting management involved will be a considerable task. With TTD there seems to be extra management needed in order to make sure that test quality is high, that TTD is being followed and that TTD is being done on every unit of code. Without many examples in industry, a company would have to innovate much of the process to fit its particular project management life cycle. I think a lot of thought has to be put into how to apply TTD in larger applications. I think definitely some concepts will work but applying it as a complete process will not work. Bibliography Wysocki, R. K. (2009). Effective Project Management. Indianopolis, IN, USA: Wiley Publishing.

re: Question 4 Re: Question 4 (Prof. Lingard) Date: Sep 12, 15:02 From: Peter Guy

Yes, it can. Most of the studies of agile methodologies have focused on small programming teams, and indeed, agile programming models do seem more natural in more intimate programming environments, but properly implemented, there's no reason why an agile development lifecycle wouldn't work in a larger environment because everything can be broken into smaller components. In fact, agile methods can improve quality in large-scale applications because they force all of the code to be transparent and broken into the smallest possible components. Because the smallest parts of the product are simple and focused, the whole product is orthogonal and robust. The biggest obstacle to implementing TDD at a large company may be the customer. The customer may not be comfortable with agile programming and may insist on using more prescriptive development processes. Existing code can also hamper adoption of agile programming techniques. If the code base of a company's existing product does not accommodate agile processes, it could take a prohibitive amount of effort to implement them.

re: re: Question 4 Re: re: Question 4 (Peter Guy) Date: Sep 12, 21:53 From: Anthony Arnold

I'm not sure quite what you mean by "orthogonal" in terms of a software product. Would you be able to elaborate on that point? I agree with you about the customer being a factor. In my industry (aviation) the customers usually have very strong opinions about the software processes my company uses, even beyond federal regulatory requirements. The customers are accustomed to a certain (old) way of development and are afraid to change. It can be very frustrating at times. It took forever to get Model Driven Development going at my company.

re: re: re: Question 4 Re: re: re: Question 4 (Anthony Arnold) Date: Sep 13, 17:54 From: Peter Guy

Orthogonality in a software context derives its meaning from the geometric idea of orthogonal lines. When two lines are orthogonal (also called perpendicular), a change in position along one line does not affect position along the other line. Likewise, with orthogonal software, changes to one part of the code do not result in unexpected changes in the behavior of other parts. Orthogonality is related to the concepts of coupling and cohesion. I read your post about the FAA requiring a certain order of events in your program lifecycle. Things like that are what I had in mind when I speculated that the customer may be the biggest impediment to using agile methodologies. It's understandable that customers require such fine-grained control over the development process: they don't know any other way (and there may not be any other way) to ensure that they get the quality they need. It's unfortunate, however, that those requirements can get in the way of changes that would potentially produce higher quality products in a shorter time frame.

re: re: Question 4 Re: re: Question 4 (Peter Guy) Date: Sep 20, 15:39 From: Cristian U.

Good point Peter regarding the possibility of some customer in not willing to apply TDD. That's a real issue and some customers might prefer to go with the traditional way of programming...

re: Question 4 Re: Question 4 (Prof. Lingard) Date: Sep 12, 21:45 From: Anthony Arnold

I think that would have to depend on the Industry in which the large company operates. I work in aviation, writing software for airplanes. We have very strict regulatory guidelines that govern what software artifacts we produce, and in what order they are produced. In particular, unit testing must come after coding is complete (for each baseline). If we wrote the unit tests before the code was completed, we would fail FAA audits. We also must have a completed design before we are allowed to code, negating part of the benefit of relying on refactoring to simplify the design process. I think that any large company developing software for regulated industries would probably not be a good candidate for TDD. A large company that is free to define its own processes can surely integrate TDD into their development methodologies. This is probably most true of companies that produce retail software, such a Microsoft, or e-business companies. The retail sector is free from heavy regulation on the process. The free-market itself will largely regulate the quality of the product. As is stated in the article, TDD is a software practice and as such it is only part of software development process. Therefore a big company would be able to tailor the use of TDD in a manner which suits large teams and projects. Having said that, since big companies are so big it is hard for them to change processes. I'm sure that changing from a more traditional development approach to a TDD approach will probably consume large amounts of money and time.

re: re: Question 4 Re: re: Question 4 (Anthony Arnold) Date: Sep 13, 18:18 From: Peter Guy

Very cogent analysis. Starting from the ground floor, in the right kind of market, even large companies developing complex products should be able to implement a more agile methodology. However, for established companies in regulated markets, switching programming models could be impossible.

re: re: Question 4 Re: re: Question 4 (Anthony Arnold) Date: Sep 23, 23:53 From: Nikolas Terani

This is a good honest assessment of the practicality of implementing TDD in a particular industry. I was wondering however, aren't unit test still performed in TDD after code generation? You still have to test for the negatives and ofcourse the suites must be run after the code has been written. But it seems as if you are saying that no test suites can be created before code has been written? That is interesting that regulations would not allow for that. There must be a reason and I wonder what it is? Your analysis brings up the very good point that know matter how logical something may be there are factors that must be considered thoroughly in deciding whether or not it is the right fit for the company contemplating its implementation.

re: Question 4 Re: Question 4 (Prof. Lingard) Date: Sep 13, 15:10 From: The B00giem0n <benjamin.riveira.832@csun.edu>

By its nature, test-driven development requires that test code be written in nearly equal proportion to actual code. For companies developing large applications, this would be an impractical approach because it would double the work of developers. Also, the constant integration and refactoring aspects of test-driven development would be an unnecessary encumbrance to companies developing major scientific/engineering software. In my opinion, these companies would benefit more from having a dedicated QA department, or by having independent contractors conduct third-party testing.

re: Question 4 Re: Question 4 (Prof. Lingard) Date: Sep 13, 15:41 From: Cristian U. <christianurs@yahoo.com>

No. I have two reasons why TDD will not work on scientific/ engineer application:  First, because the initial design is very important in a huge application. The TDD is associated with smaller project. Usually, for any software product, if too much time is spent on testing, the elaboration of the software will be delayed too much. Taking in consideration that the testing in Test Driven Development is done by the programmers, it will take way longer for the final version of the product.  Second, writing tests for an scientific/engineering software products requires advanced knowledge in math or physics for example. So, the programmer will not be the right person to start testing. Normally, the complex testing will be done by a person which has a solid background in what he/she is testing.

re: re: Question 4 Re: re: Question 4 (Cristian U.) Date: Sep 21, 20:58 From: Anna Brjezovskaia <Anna.Brjezovskaia.509@csun.edu>

I do agree with your first argument, but I am not sure about the second one. You are right that advanced knowledge may be needed to test a scientific project. But on the other hand developing the tests might help the developer to understand what he is trying to code. I think that the understanding of the subject is important to avoid misinterpretation of requirements and producing efficient code. I think that from this position the Test-first approach might be helpful.

re: Question 4 Re: Question 4 (Prof. Lingard) Date: Sep 14, 10:17 From: win <win.phyoe.58@csun.edu>

I found that the article does not provide enough experiments of TDD with large organizations so we will need more research on TDD working at a large company developing major scientific/engineering applications and should evaluate these results. Since TDD focuses on unit test of every small components of the application, it can be difficult to integrate these components in large scale organization and also needs to take account into consideration how to integrate these components as a whole while developing unit tests or more structured method to integrate these components.

re: re: Question 4 Re: re: Question 4 (win) Date: Sep 15, 20:05 From: Peter Guy

I, too, would have liked to have seen more empirical evidence of how well (or not) TDD works, especially after having read some of the next assignment. Software inspections have apparently been under heavy scrutiny for 20 or 25 years: the paper cites numerous in-depth experiments. I think that some day, we will see more metrics; we just have to let the research catch up with the interest.

re: re: Question 4 Re: re: Question 4 (win) Date: Sep 15, 20:30 From: Anthony Arnold

I too found the lack of data somewhat troubling, especially for a methodology that the author states is probably in such wide use. I wonder why there seems to be so little data about the use of agile or XP methods in general compared to traditional approaches?

re: re: re: Question 4 Re: re: re: Question 4 (Anthony Arnold) Date: Sep 15, 22:02 From: The B00giem0n <benjamin.riveira.832@csun.edu>

Perhaps it has to do with the lack of documentation associated with most agile development methodologies? Nobody documents the process, so nobody knows how much it helped? No, but seriously, I suspect it's just that agile development has only been recently embraced within the industry. Although agile been around for a while, most companies have stuck with traditional, or familiar, development models. For example, the company I work for has been in the software business for 39 years, and we've only been practicing agile development for the last 2 years or so.

re: re: re: re: Question 4 Re: re: re: re: Question 4 (The B00giem0n) Date: Sep 21, 00:10 From: Eduardo Borjas <epb55720@csun.edu>

You stated... "Perhaps it has to do with the lack of documentation associated with most agile development methodologies? Nobody documents the process, so nobody knows how much it helped?" Have you ever tried to get more than 10 people in a meeting and have them hash out one problem, let alone a whole project full of them. As projects get bigger, you need documentation so you can properly communicate between teams (especially since in larger projects there are a TON of interoperable components, if there weren't each project would be in its own sandbox). Now the other super important aspect is how do you communicate with people when they are not collocated but rather 12 time zones away. You are limited to only a few hours a day where you can talk to them (if they are available). If you need to setup requirements, designs, etc; it becomes absolutely vital (for time and clarity) to document as much as you can.

re: re: re: re: re: Question 4 Re: re: re: re: re: Question 4 (Eduardo Borjas) Date: Sep 23, 19:27 From: The B00giem0n <benjamin.riveira.832@csun.edu>

I was attempting to be facetious with my response, sorry if it didn't translate. My comment was a reference to Professor Lingard's SWLifeCycleModels.ppt, slide #18, which says that Agile Methods Emphasize: "Working software over comprehensive documentation."

re: Question 4 Re: Question 4 (Prof. Lingard) Date: Sep 15, 18:22 From: Edfan T

It might not work since TDD is effectively designed for small process model (such as Agile) since: 1. Agile software development method does not work in large project/company. 2. Computer scientists are not engineers; therefore, need a lot of planning ahead for future references which contradicts the agile development method which requires little planning for short term duration; in addition, working in a large company that developing major scientific/engineering applications require plenty of programmers and engineers within a team and again contradicts the agile development method which requires 5-9 people.

re: re: Question 4 Re: re: Question 4 (Edfan T) Date: Sep 15, 20:34 From: Anthony Arnold

I find it funny that you state "Computer scientists are not engineers", when you then next state that we need lots of planning. These two ideas seem to be at odds with each other. Isn't engineering all about due diligence and doing the necessary analysis to support the end results? Planning would seem to be a natural fit for Engineering in general. As far as how planning fits in with Agile processes, I fail to see how they are incompatible. Especially since Agile processes tend to focus less of paperwork, I think it is very important to plan the direction and basic ground rules of any project using those processes.

re: re: re: Question 4 Re: re: re: Question 4 (Anthony Arnold) Date: Sep 15, 20:43 From: Peter Guy

Are we (programmers) artists or engineers?? The age-old question. Well, not age-old, but at least a generation or two old. :-) I'm a fence-rider on this one: I feel like I am some of each.

re: re: re: re: Question 4 Re: re: re: re: Question 4 (Peter Guy) Date: Sep 21, 17:37 From: Edfan T

Maybe I didn't make myself clear or I chose wrong words; maybe Peter is right, "programmers" might be the right word. I notice that we, programmers, are also "engineers" for our own code because we are responsible for the structure of the code and how things work; in addition, we, programmers, are also "artists" or "architects" or whatever term it is since we design the code so that they look neat and readable. Anyway, my point is that programmers and engineers (those who do not code) have different roles though they have to work side by side and have the same responsibility to meet the end results. When I said they need a lot of planning ahead is that imagine if they (engineers and programmers) are within a team, they have to talk about all their plans ahead whether in how they approach problems, resolve them, or maybe they have different ways of thinking. Now if we compare this team to another team that only consists of programmers, wouldn't the second team be needing less and faster planning ahead.

re: re: Question 4 Re: re: Question 4 (Edfan T) Date: Sep 15, 21:41 From: The B00giem0n <benjamin.riveira.832@csun.edu>

I have to disagree because I work for a relatively large company that is thriving under an agile (Scrum) software development methodology. Our software is used by thousands of real estate associations nationwide and it is in a state of constant change; we're always working on new features or making customer-suggested improvements. Our programming and QA departments are broken into specific project teams consisting of the magical 5 to 9 people. The team I work on consists of 8 programmers and 1 QA tester. Since Scrum prescribes cross-functional teams, us programmers have also been trained in QA testing techniques. My team has not yet adopted TDD and unit testing, but other teams in our company have, and these seem to have helped improve the quality of their work.

re: re: re: Question 4 Re: re: re: Question 4 (The B00giem0n) Date: Sep 21, 20:55 From: Edfan T

Yes well, my initial reflex thought was just based on the theory, but after a while I have been thinking about it that no matter how big a project is, it can be divided into smaller parts.

re: Question 4 Re: Question 4 (Prof. Lingard) Date: Sep 15, 19:42 From: Troy Mockenhaupt <troymock88@yahoo.com>

I think that can be effective on a large scale but only if its integrated with another strategy like XP as discussed in the paper. If the testing strategies are carefully designed and implemented it should help to reduce the amount of development time that TDD can add. It can then help to greatly decrease the number of defects found in a product released by the large company. Most software and programming can be broken down into smaller parts which will greatly help the effectiveness of TDD regardless of company size

re: re: Question 4 Re: re: Question 4 (Troy Mockenhaupt) Date: Sep 20, 23:40 From: Eduardo Borjas <epb55720@csun.edu>

Let me start by prefacing that I am going to discuss TDD as a part of agile development. Most people say that agile only works for small teams. Now there have been points made that if scaled correctly, agile development can work for large scale groups. I think that this is not the case because look at the fundamentals of agile development:     * Individuals and interactions over processes and tools     * Working software over comprehensive documentation     * Customer collaboration over contract negotiation     * Responding to change over following a plan [Source Wikipedia: http://en.wikipedia.org/wiki/Agile_software_development] The key points here are the first two, working software and individuals/interactions. If you are minimizing the documentation, how do you properly communicate between teams? It is next to impossible for 10+ people to be on the same plan but it is essential in larger projects (imagine having 10+ talking heads going on at the same time?). According to the scaling technique a single point of contact would need to be used by each team to communicate with the other team contacts. This information bubble up is mostly using verbal communication. What happens with information when one person tells the other person, and the other person tells someone else? The message is changed many times over. This methodology would have to be altered somewhat to facilitate larger groups. Regardless of my statements there may be a way to make this all work. It just needs to be studied, applied and then analyzed.

re: Question 4 Re: Question 4 (Prof. Lingard) Date: Sep 15, 22:53 From: Martin

I believe that TDD could work in a large scientific/engineering project but would run into some obstacles that could make it difficult to implement efficiently. I have had experience working on a tailored Agile project which included TDD in the early stages. One of the immediate challenges that surfaced was caused when the approved requirements set was divided among developers or teams to implement. Each requirement was not always testable within the bounds of the developer responsible for implementing the code. Testing sometimes had to occur at one of the integration cycles. When the developer or team responsible for the code does not actually write or run the test, TDD loses some of its benefit. Developers now have to wait for other teams to finish before they can write/run tests. Refactoring becomes more difficult since integration has already taken place to some extent. In the end, it turns into a more traditional post-development test activity than the true TDD intended.

re: re: Question 4 Re: re: Question 4 (Martin) Date: Sep 16, 16:04 From: Jack Weaver <weaver.jack@gmail.com>

On the Agile projects I worked on in which we used TDD, the requirements of our individual code were testable, even without other code (dependencies) being finished yet. Interfaces were implemented, and mocked using a Mocking framework (google Mockito), and allowed the team to move forward without waiting on eachother. The Interfaces were quickly brainstormed and written (it's a contract), so the whole process did not take too long to get up and running. When code was refactored, it was refactored out of sight of other dependent code (the Interface/contract did not change, only the implementation). Did your team use a mocking framework to help expedite waiting on dependent code? (if I'm understanding your response correctly! :-))

re: re: re: Question 4 Re: re: re: Question 4 (Jack Weaver) Date: Sep 27, 18:47 From: Martin

I see your point. No, the project we were on did not do any type of design steps prior to breaking down the requirements. At the time we thought that true TDD did not require such steps. In hindsight, I would definitely do some preliminary high level design criteria like you mentioned. Additionally, I think the break-down of requirements into units needed to be abstracted more. The more I read about TDD it seems that the units are pretty far down from the customer specified requirements.

re: Question 4 Re: Question 4 (Prof. Lingard) Date: Sep 15, 23:49 From: Anusha <anusha_nataraj@yahoo.com>

Test Driven Development strategy can be applied in large scientific and engineering applications because of following reasons:- 1) One of the major issues faced is lack of clarity on requirements due to the large number and complexity. Applying the test-first strategy helps in better understanding of each requirement. 2) Designing a test, acts as a mirror of the application, which inevitably leads to design of the application. 3) It ensures that clean working code is developed, which is essential in large projects where different teams contribute towards the project.

re: Question 4 Re: Question 4 (Prof. Lingard) Date: Sep 16, 01:51 From: David H

4.For a large software project, I believe that using TDD would not work. The main problem I forsee is the design of the actual application. If the application is very large, then many of the design decisions need to be made prior to actual development of the code, otherwise many problems will arise. From how this article represents TDD, it seems that a lot of the design decisions are made accidently on how the code ends up after refactoring, and I believe that brings too much risk to a project.

re: re: Question 4 Re: re: Question 4 (David H) Date: Sep 20, 23:44 From: Eduardo Borjas <epb55720@csun.edu>

I think you make an excellent point here. In large projects you can't have 10+ people going off in their own directions. Obviously the counter point to that may be that teams will plan the activities out beforehand and then apply TDD to each unit piece of code in each task.

re: Question 4 Re: Question 4 (Prof. Lingard) Date: Sep 16, 14:07 From: Jerry

I believe this can work in a large company developing major scientific or engineering applications. However, dividing the requirements/tasks among the smaller groups may prove difficult since a group may not be able to test the code due to the splitting of the tasks. However, if divided correctly, the smaller-group environment is beneficial because breaking down into components means they could be more focused and directed in the approach without worrying about entire application as a whole.

re: Question 4 Re: Question 4 (Prof. Lingard) Date: Sep 16, 14:14 From: Alireza B. Shad <alireza.shad@csun.edu>

4. Yes, I believe this strategy would work for large software development companies. TDD’s ability to improve software quality and programmers' productivity enables the software engineering community to produce reliable products, as well as assures reusability and quality maintenance of software.

Answer 4 Re: Question 4 (Prof. Lingard) Date: Sep 16, 14:17 From: Arastu Shah <arastujshah@gmail.com>

Yes it will work because automated unit testing and unit testing frameworks reduce the effort of testing, minimizing a large quantity of tests to a simply a button click. The programmer can immediately execute the tests after they are written. TDD has the ability to detect defects early and bring significant improvement in software quality and programmer productivity. The only downside I see is that requires a good deal of discipline on the programmer’s part and also needs more of his time and efforts in developing automated tests and documenting it as well. Also that is misunderstood because of its name as people think that it is just another testing process.TDD does not fit every process as well.

re: Question 4 Re: Question 4 (Prof. Lingard) Date: Sep 16, 14:30 From: Harvey Alexian xharvey-ax2sbcglobal.net

It’s hard to see how can we possibly apply TDD to a large , complex software project with concrete requirements and design .This is especially true for complex scientific and engineering projects for two main reasons. 1- These type of projects need a large number of scientists and specialists to collaborate together and this fact makes it hard to implement extreme programming methodology and subsequently TDD. 2- In order to write reliable test cases we need to know the exact output data to test our code against them .In a complex scientific and engineering software, we often don’t know the exact output data, or because of the nature of problems, and their complexity , often it’s not easy to break down the project into very small “tasks”, which is the starting point for writing unit testing code. Writing test cases for large “tasks” is not easy and it may take much more effort and time to develop them than actual software itself.

re: Question 4 Re: Question 4 (Prof. Lingard) Date: Sep 16, 15:45 From: Jack Weaver <weaver.jack@gmail.com>

In short: Yes. I have myself worked at a very large corporation, in which internal research and development programs were currently being worked on that made use of a TDD approach (the programs were very scientific). The management there made sure we were aware of the practices, and provided a close "mentoring" atmosphere in which we could learn a TDD approach to software. It worked well for them, producing software in which no real known solution existed before (it was very research-intensive) with a minimal set of provable functionality (the test cases ensured the code which passed it made good on it's contract). The Test units then also became part of the deliverables, making the stakeholders happy. Yes it would, and does, work in a large company (corporation) developing scientific applications.

re: re: Question 4 Re: re: Question 4 (Jack Weaver) Date: Sep 19, 12:05 From: Peter Guy

Good real-world example. I like that the tests were included in the deliverables. That way the client can verify conformance with just the click of a button. Probably not really _that_ simple, but I'm sure the tests still make conformance testing highly available to the client. you specifically mentioned several aspects of your company and development process that sound like a good fit for TDD:   - focus on mentoring   - intensive R&D (lots of designs and re-designs)   - limited number of tests on the end product In your opinion, are any of these aspects vital for the success of TDD? In other words, would TDD still work in your company if, say, the end product required many more functional tests than it does?

re: re: re: Question 4 Re: re: re: Question 4 (Peter Guy) Date: Sep 23, 17:06 From: Jack Weaver <weaver.jack@gmail.com>

TDD would definitely still work. It's more than just deliverables, it also helps the programmer. I believe though that it's limited when the more experienced coders/developers use it. Someone who has been developing software for decades will have much better code (Design, etc) than someone who hasn't. So it's limited in that scope, but I still believe it has its place. It can also be used (sparingly) as a small metric on design complexity (the key goal of software engineering "dealing with complexity"), because the more complex the test cases are, generally the more complex the code it's testing is. Either the test case is not a true "Unit" case and is trying to test too much, or the SUT (System Under Test) is too complex and needs to be re-factored. Where I worked, there was a huge focus on flexible and extensible software, so a key focus was on how complex the software was. TDD helped in that regard (along with Cyclomatic Complexity, Efferent coupling, etc).

re: Question 4 Re: Question 4 (Prof. Lingard) Date: Sep 16, 16:01 From: Ricardo Miron

I think that TDD could work in a scientific/engineering application as long as a process like XP is used. The only downside i see is that a project may take longer to complete.

re: Question 4 Re: Question 4 (Prof. Lingard) Date: Sep 16, 19:06 From: Anna Brjezovskaia <Anna.brjezovskaia.509@csun.edu>

I think it would be a good thing to try because the TDD would help to become aware of the requirements which is sometimes really difficult in the scientific applications. I think the use of TDD would help the developer to understand what they actually want to achieve. Despite of this positive I think it might be problematic. As it requires a lot of discipline to maintain the test cases, and in big groups it’s much more difficult to control this. And it might seduce the developer don’t really understand the scientific problematic behind the program and just try to adjust the outcome to the expected outcome

re: re: Question 4 Re: re: Question 4 (Anna Brjezovskaia) Date: Sep 22, 19:34 From: Ricardo Miron

I agree with your point that it is tough to maintain disciple in large projects and therefore TDD may not be suitable for a project of this size.

re: Question 4 Re: Question 4 (Prof. Lingard) Date: Sep 16, 23:32 From: Nick Terani

I am skeptical as to the effectiveness of this strategy with a large company developing scientific/engineering applications. One of my first concerns is that scientific applications are normally built in C and this practice is designed to be incorporated with Object Oriented Technologies. Object Oriented Technologies are often used for applications that require strong interfaces for human interaction. It seems reasonable that by examining what the program must do in the terms of test cases could help identify how the various classes might interact with each other and lead to design decisions. I am not so certain that this would play out so naturally within the context of a scientific application. I am not certain that a scientific application can be designed without a more rigorous design process. Additionally, the idea that test cases help to determine what the program should do inherently implies that the programmer has a tremendous amount of domain knowledge. Should it not be the customer or user who helps to determine the requirements. Perhaps, TDD is just merely an aid to requirements elicitation and does not substitute traditional elicitation practices, but nonetheless it does not seem likely that you could proceed in a scientific application without a clear understanding of the requirements nor the design. It does seem possible however, that the notion of developing test cases first could be a beneficial practice in code generation. It seems that it would almost be akin to the cleanroom methodology where nothing gets added until it is proven to be correct. However, instead of proofs, you are using test cases to verify that the code is doing what it is supposed to do before you move forward. Potentially, this could be beneficial to mission critical systems like scientific applications.

re: Question 4 Re: Question 4 (Prof. Lingard) Date: Sep 22, 10:05 From: Omer

The strategy would work on development of any size and duration. Every development effort, large or small, by whatever process eventually comes down to writing one function, one method; and then another. It is not possible to write a method or function unless on knows what are its expected input, output, and transformation (the relationship between a specific input and a specific output). By defining these first as a method or function signature and then as test cases one has formalized what it needs to do. One can use this to check with the designer, the customer, or whomever applies to ensure understanding before coding. The fact that the tests are now coded has several benefits: 1) it is easier to code once this is done; 2) it is easier to confirm that the product (the code produced) is good before handing it over; 3) most important, one does not have to be nervous about making later changes, even years after the original programmer left. For if the new code pass the existing tests, and possibly an additional new one, one can safely assume one has not broken old functionality by introducing new.

re: Question 4(Cristian) Re: Question 4 (Prof. Lingard) Date: Sep 22, 15:04 From: Anusha <anusha_nataraj@yahoo.com>

I agree with Anaa with regards to your second point. Regarding first point : TDD assumes that there can be an initial deisgn.Large projects can be divided into smaller projects and hence TDD can be applied to large projects.The test case developed by developer need not be very elaborate, however it helps in better undertsanding of the requirements and aids in developing the design. It might take a bit longer for the product to reach the final version but not too long to affect the product.

re: Question 4 Re: Question 4 (Prof. Lingard) Date: Sep 24, 09:55 From: Velimir

I think that TDD can be used in a large scale project. This will increase the time the product is being developed but at least the end product should be better. In smaller units where test can be omitted or the programmer feel confident(senior programmer is working on it) in his/her work test cases can be skipped. But there is the other site where “The developer must maintain both the production code and the automated tests ” which can be a little overwhelming in a big scale product. In overall developing a big project with TDD can be very helpful. As the paper says “TDD is about analysis and design than it is about testing” so I will say only using the first two aspects of TDD – analysis and design can produce a enhanced code structure and pattern of the code base of the product.

re: Question 4 Re: Question 4 (Prof. Lingard) Date: Sep 28, 21:49 From: Sphoorti Madugula

I think using a software development methodology such as TDD would be highly beneficial when used in a company involved in developing major scientific or engineering applications. TDD, in my opinion, is slightly like the concept of ‘rinse and repeat’. Being employed in areas where a number of iterations or repetitions of testing takes place, it would prove to be the best practice. Basically, any static process that involves a lot of thought for design and implementation would be benefited if TDD is utilized. Dynamic or constantly transforming software products may not gain much if TDD is made use of. Since using TDD adds to the existing burden developers have, I would say that as long as there are testers or product managers or business analysts to help in the design and testing process, TDD would help. If developers are overloaded with too many tasks, the practice may prove to be less fruitful, because their focus would be divided and their efforts on various aspects inadequate. Not only to make developers less weighed down, but to be sure that their lack of knowledge, in the scientific or other fields, isn’t damaging or causing setbacks, it would be necessary for someone, like product managers or business analysts or researchers who have that education or expertise, to take over that particular task (designing the application or software) so as to fill in the missing pieces.

[ Add Message ]  to: "Test-Driven Development"

[ Admin Mode ]  [ Show Frames ]  [ Help for HyperNews at hyper.vcsun.org (group: /rlingard) 1.10 ]