Hot answers tagged

6

The basic workflow for TDD is commonly known as "Red; Green; Refactor": Red: Write a failing test Green: Modify the code to make that test pass (without any existing tests failing) Refactor: Tidy up the code to better incorporate the change. There are numerous resources that explain this process in details, eg The Cycles of TDD It's unclear to me as to ...


5

TDD revolves mostly around unit testing, this answer is going to cover that. Why do you make applications? Do you make them to see see that C# works well, or do you make them to solve a problem presented by your client (be aware, sometimes the client may as well be you)? Unless you are a .NET developer working for the Microsoft company and are actually ...


4

There are a lot of articles, books, blogposts, conference talks... that deal with this issue. Michael Feathers' Working Effectively With Legacy Code is by many considered to be one of, if not THE best books on the subject. There is a twelve-page PDF available for free online that formed the basis of the book and should serve as a good starting point. Don't ...


4

After having written lots of test, I am strongly in favour of splitting up large methods, and of testing private methods. Splitting up functionality into smaller steps has two great advantages: By introducing a name for an operation, the code becomes more self-documenting. By using smaller methods, the code is simpler and thus more likely correct. E.g. you ...


3

Adding unit testing to a project in retrospective is usually more pain than it is worth. There is a reason why the red/green/refactor workflow mandates to write the tests first and the code which passes them afterwards. In order to be properly testable, the whole code architecture must be designed with unit-testing in mind. You need to follow patterns like ...


3

TDD isn't about debugging, it is about proving the code functions as expected. Strictly speaking, the tests should have been written before the code but you are where you are. Unit tests benefit future developers since failing tests should raise a red flag that they've inadvertently broken something and should attend to it. That isn't to say there is no ...


3

You will normally keep your tests in a separate folder hierarchy as they usually aren't part of the binary you ship, and it's just simpler to not mix them up, but you keep them in the same repo and branch because they belong together in source. As for where you work, TDD means Test Driven Development, which means you first write a (small) test for the ...


3

For me there is a simple criteria to decide if automatic tests are needed: Are you planning to evolve and maintain the project? "Yes" - you should write tests. There are some cases when you can go without tests, mostly it is "do once and forget" type of work, like small web-site, CMS setup, etc. Everything which you do quickly, test if it works and forget ...


2

The tests aren't there to ensure you write the code you want to write. They are there to ensure that three years from now, you don't accidentally change the way the code works through a seemingly unrelated change, causing unintelligible defects. Tests are insurance against the future. Never remove the tests.


2

I think you listed the differences very well in your answer, however I'll add my some of my opinions on how I view the two approaches. AAA is very useful for me when I'm testing my own code. If I'm working on a project or a library for myself, AAA is the way that I go. It lets me set up whatever I need to execute my test and then just test it. It's ...


2

I guess it's dependent upon the framework you're using. Generally, so far as my understanding, AAA is supported by the NUnit framework, and thus is the natural choice in that regard. As for the theoretical differences between TDD and BDD, they appear to be slight. See this link, someone more qualified than myself to give you an explanation.


1

I have always followed the maxim that a unit test tests one thing and only one thing. Programming such that each method does one thing and one thing only, should mean you can write a unit test for that method fairly easily. If your method calls out to any other services or classes, then you should mock those so their behavior during the test is completely ...


1

At what point in that process should I really begin testing? Well, you asked specifically about tdd, so there's really only one correct answer: Before you do anything else. Test-Driven Development and Design is called Test-Driven, because the Tests drive the development and design. The tests tell you when to start writing code. They tell you what to ...



Only top voted, non community-wiki answers of a minimum length are eligible