Tag Info

Hot answers tagged

21

There are 2 books I recommend reading as they will help with moving legacy code to TDD: Working Effectively with Legacy Code and Brownfield Application Development in .Net (newer book, but .NET based). Since I'm writing unit tests AFTER the code, should I first refactor, do my own regression tests, then continue using the TDD steps (write failing ...


15

I would suggest that you go back and do those unit tests when you are required to refactor that area of legacy code. The approach for do this is described in this question. When you are working with legacy code with no unit tests, its the same principle and techniques to add them regardless if you are doing TDD or not. I highly recommend Working ...


10

IMO you should go ahead and write the unit tests for passing statements before doing any refactoring. The reason is because you want to be in a known state before making changes.


7

The Three Laws of TDD You are not allowed to write any production code until you have first written a failing unit test. You are not allowed to write more of a unit test than is sufficient to fail—and not compiling is failing. You are not allowed to write more production code that is sufficient to pass the currently failing unit test. ...


6

One of the realities about corporate politics (I hate to say it, but it's a big part of our job) is that everyone wants to put out the image that they're open minded and willing to do what's best for the company, but in reality most people want to go with what is safest for their career and with what they know and are comfortable with. < tangent > If ...


6

TDD is, in its truest sense, exactly as Aruna described it. The developer writes automated unit tests, watches the test fail, then proceeds to write the code that the unit test was meant to test, codes until it passes, and then refactors, all the while maintaining the core unit tests. Ideally (in my world at least), all of the tests should also be ...


6

The first thing you want to do here is perform some bug triage. Problems your team finds during feature testing will be one of: something introduced by the changes something that was there before and doesn't have much if any impact on the changes something that was there before and has a major negative impact on the changes The developers in the team ...


5

I agree that your tests will require ongoing maintenance (as does most test automation). There are tactics for organizing your Selenium tests so that maintenance is easier, but they depend upon how the user interface is written, whether the developers help maintain the tests, and the manner in which the user interface changes. In fact, the quicker the user ...


5

TDD is generally code designed by developers first writing unit tests. There is a fundamental difference in how developers and QA people approach the concept of test. It is more helpful to think of unit tests as code contracts. These will be updated and changed over time and that is the primary difference. To a QA person a test, once working, should always ...


4

Ideally not! I have suffered under the same lack of understanding the concept when I first wrote code. Think of unit tests in TDD more as documentation of the written code. BDD design may be closer to what you refer to. Let me try and example: I have a requirement to take a data stream and transform this. In a specific way. The documentation can be an ...


4

Welcome to SQA, Tim. I do not create a new test case for every bug. I believe testing is about managing risk. If I believe the risk of a a bug reappearing is low, I will test the bug when the developer says it is fixed, but I will not re-test it for every subsequent release. Judging risk is subjective, and sometimes my judgement is wrong, but I think ...


4

You NEED a test to show that the refactoring didn't break anything. I am a big fan of the A B theory based test that @Squirrel described. I am also a big fan of characterization tests from (working w/legacy code) via Michael Feathers. Personally, this is the technique I use in 90% of my work with legacy code (it's a variation of characterization tests). ...


4

I think Stacy calls it 'Branching by Abstraction' For legacy code the best approch I've found is to find pinch points in your code where it's easy to insert an interface covering the inputs and outputs. Copy your first implementation, refactor, and then have a regression implementation that runs the old way and the new way and stops dead as soon as any ...


3

Writing and maintaining automated tests is a big investment and it is ok to start slowly It is expensive to write and maintain automated tests. If the tests are written in an ineffective way, the investment may not pay off. Similarly, if the tests require a great deal of maintenance, either because of how the tests are written or because the interfaces ...


3

Spiff, As you suspect, there are no magic bullet answers to your question, but I can offer some suggestions to consider. Wherever possible, look to code any particular action exactly once and reuse it multiple times. Whereever possible, drive your tests with a combination of object-oriented and data-driven test code. Where you can string together a ...


3

Another thought to add to the well-written answers: In the question, the author mentions a developer's objection: adopting the Selenium tests to changes (like a changed button_id or something) would take too long. Since UI tests are brittle with respect to the underlying structure of the UI, UI automation success depends on successful collaboration ...


3

The key question is can you afford for it to go wrong? And the answer to this quite often is dependent on how quickly you can fix the problem if it occurs - debug it until it works in production. While not a nice place to be, for some things that once done, should never need to be revisited you can get away with having no tests. If your business / lives ...


3

Point of specifications should be communicating needs of the user. There can be different implementations which all fullfill the same specs. On the other hand tests in TDD should help programmer to ensure that implementation works correctly. It is true that best specifications are testable and if you can automate testing of them, it helps ensuring that ...


3

No. It's too late for the tests to affect the design, so you can't get the major benefit of TDD. What you can do, however, is to write tests as you work on the code. Say you've got a method that's too long. Write a test of a little piece of it, assuming that little piece had been extracted into a new method. Now extract that method. Or say a bug report ...


3

I had been into Test Driven Development and this is the way we approached it. The Developer develops automated unit tests even before he starts coding. Suppose there are 18 tests to validate the payment method. Before he writes the code, all the 18 tests would fail. After the coding is completed he would ensure that all the 18 automated unit tests are ...


2

None of TDD is manual testing. The whole idea of the "Driven"-part is that you get a collection of tests that run every time you change something to your source code, in order to maintain stability and prevent regression issues. Tests don't, howevery, need to be unit tests. If you prefer, they could be automated UI tests for example.


2

Covering the existing code with unit tests might be worthwhile if you target the area of the code that have higher probability of being changed in upcoming releases. That way you will build a safety net around the code that likely will be changed (new features, refactoring, bug fixes etc). Targeting the code that has higher logical complexity and ...


1

I think Tom's answer explains why TDD doesn't work well with reviewing unit tests ahead of time; unit tests become part of the implementation process in TDD, and are part of a tight cycle between testing and implementation. In other words, you can't write unit tests before coding if you are using TDD. Reviewing Cucumber-style acceptance tests, however, ...


1

Doesn't TDD mean the developer has the design suggested to him as he codes the tests rather than being handed a spec to write code to ? Don't you then also miss the dev having the conversation with the customer to understand their needs ?


1

I believe the answer is "it depends". If you're talking about a unit test, why not? These should be the bulk of your tests anyway, and usually run very fast. But it may not be worth the time or money. If you're talking about functional tests, probably not. But again, it depends. Was the bug a cross-browser or OS issue? Was it a logical bug or typo? Will the ...


1

Creating a test based on a bug is a good way to drive the development and provide an acceptable pass condition for the fix. While i agree that smaller bugs that are hard to re-create probably aren't worth building a test around, there may be some merit in seeing how often it does actually pop up and the test does fail.


1

Let me take BDD out of the equation for a moment and answer your question about what the recommended scenarios are for Selenium automation. I have found that there are 2 primary areas that UI automation should focus on to have the best ROI: The first is UI specific functionality, for instance anything that is driven by javascript on the page (including ...


1

As Edu pointed out you're mixing up acceptance testing and test driven development. Acceptance tests is to confirm you built what the customer wants. Test driven development is not only to confirm you built what you think the customer wants but first and foremost to help you design a good solution based on your current understanding of what makes good ...


1

This is a really interesting question, but it seems like the place to start is not at "what is TDD?" but more like "how can we not do things that have an overwhelming probability of shooting ourselves in the foot?" You might look through a post by "Joel on Software". It's something of a canonical reference for best practices around software development in ...


1

I wouldn't worry about redundant tests at first. It's much better to test a piece of code twice than not at all. The only way to accurately determine whether your tests are redundant is by using a code coverage tool (or extensive logging). However, as Kate Paulk states, there are no magic/silver bullets with testing, or software development in general (of ...



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