Hot answers tagged

8

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


8

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


8

Taking the waterfall model in agile would be a good idea but there seems to be a misunderstanding on your part regarding the concept of test driven development. Test driven development doesn't mean agile, neither does it mean just writing test cases early. It means that tests are written first and these tests drive the programming. That means the ...


8

TDD (Test Driven Development) Who's involved: Developers Summary: Developers start writing code by first defining tests (in general unit tests). It could sound strange, but this practically guarantees a high code-coverage and in particular it forces developers to think about what they are doing. TDD can be applied to any kind of software. BDD (Behaviour ...


8

The TDD cycle is more a development cycle for a developer, to quote James Shore, The Art of Agile, Test-Driven Development chapter: Programmers new to TDD are often surprised at how small each increment can be. Although you might think that only beginners need to work in small steps, my experience is the reverse: the more TDD experience you have, ...


7

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


7

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


7

The short version: regardless of the development methodology, your role is to provide information about the overall quality of the application. You do that via testing anything that isn't included in the developer-maintained automation, and reviewing the developer-maintained automation. The long version: This question and its answers is a good starting ...


6

Both are a form of test driven development, since you write the tests upfront. The main difference is that TDD tests are technical tests often unit-tests created during developing of a feature and are written just before you implement a part of the feature in the code-base. Where BDD tests are often written before the coding starts and are human readable and ...


5

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


5

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


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

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


5

Yes, proper dependency injection benefits testing and TDD greatly because it allows to test individual components/dependencies easier - mocking/stubing each of the dependencies without affecting any global variables or global dependencies which other parts of an application may depend upon or other tests might use. I found it quite handy to write unit and ...


5

I believe that the strongest instrument for filtering such a-low-quality tests is a code review. You can power-up your code review with mutational testing techniques which will help you to detect the tests which probably do not introduce any value to the overall project scope. Here is the example of mutational testing framework where you can pick some ...


4

This book is exactly what you need: Working Effectively with Legacy Code by Michael Feathers. Michael offers several approaches to TDDing legacy code. One of those is: Before you add a new feature, write tests in the area that you will change. This approach gives a number of benefits: Writing the tests will give you a certain amount of confidence that you'...


4

Adding my view points here. TL;DR : BDD focuses on the behavioural aspect of the system rather than the implementation aspect of the system that TDD focuses on. BDD gives a clearer understanding as to what the system should do from the perspective of the developer and the customer. BDD allows both the developer and the customer to work together to on ...


4

The TirePressureMonitoringSystem coding kata is an situation that is very hard to test without dependency injection. It simulates an Alarm which is part of tire pressuring system. The implemented sensor gives back random data. The task is to restructure the Alarm class, but not the sensor to make it unit-testable. I think the kata showcases why DI is so ...


3

Lets assume that you go with the TDD approach to writing your tests. In this case you should be focusing on writing tests for the code you are implementing. If in this case you are working on client side code that makes calls to a server you should be working with unit tests initially that test the calls you are making. Using stubs and mock objects you ...


3

In TDD you write the minimum amount of code to pass the test case. That test case, of course, should only be testing at a unit level. You want to test individual pieces, so you write test cases to cover limited functionality(mainly 1 feature). Your test cases will end up acting as documentation for your system and low-level regression testing. TDD is ...


3

In my experience, you can't sell new development processes. The only path I've found which works is to simply start doing it: Only develop with TDD from this point forward. You'll still deliver your code on time, but it'll be more maintainable and have far fewer bugs. You'll feel much less anxiety and be proud of your work. After a little time, management ...


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

I'd plan it this way: The specific tests that are written 'before the code' are unit tests that are written by developers just before they write the actual code. It should only take 5-20 minutes to write a simple test. The test is written, the code is written for it and then the test is changed or the next test is written and then more unit level code is ...


3

If developers also write unit tests, then what's the point of having special testers in our team and should we replace testers with developers? Unit testing is not the only kind of automated testing. Integration tests, performance tests, scalability tests, and fault tolerance tests are all examples of automated tests that are not unit tests and that a ...


3

Test-Driven Development is a way of of developing software, its a practise. It is a process you can follow. You write a failing tests and implement just enough code to make the test pass, afterwards you clean or refactor your code and create a new failing test. Repeat this cycle until your software is done. Mostly TDD is used with unit-tests and less with ...


3

D) There is no code This is the one and only correct answer, because the idea of TDD is that you only implement code for which you have a failing test. It prevents you from implementing things you do not yet need. This comes from one of the ExtremeProgramming practises YAGNI. One way XP’ers would keep themselves honest is to insist they write a failing ...


3

To learn TDD I suggest doing a kata everyday. Start with the String Calculator Kata and do it test-driven. The coding dook handbook has loads more example kata's to practise and learn the following skills: test design refactoring safely naming tests driving code with tests designing clean code Also read Test Driven Development: By Example


3

Use cucumber. Specflow is a part of cucumber family that is developed for .Net world. So if you do not need .Net but need Java, just use the solution that was originally intended for Java


3

You can use some Boundary Value Analysis to filter out the list of test cases. You would probably do a better risk analysis than anyone else in this case, but I can imagine the following as the riskiest test cases: Monday 8 AM Monday 8 AM +- 1s Monday 8 PM Monday 8 PM +- 1s Saturday 10 AM Saturday 10 AM +- 1 s Saturday 4 PM Saturday 4 PM +- 1s Some ...


2

Just like with everything else in IT - it depends. Depends on whether the bug can be easily reproduced, it depends on how severe this bug is, depends on the chance of the bug reappearing again somewhere in the future. Someone said before me that it's all about managing software testing risk and I agree with it. While it may seem to be tempting to cover ...


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