8
The biggest problem I see with this is that you're looking at a mini-waterfall rather than a sprint. The description you're giving above forces the team to deliver all or nothing. What if they have 12 items in the sprint and deliver 9? Does that mean you won't test or release what has been done? If so then I dread your release schedule, every time any team ...
8
I remember reading on someone else's post that test code should not be treated as normal code but as small whole programs and that is an idea I really like and would like to refer to when discussing with other engineer colleagues, but is not unanimously shared.
Working Effectively with Unit Tests, by Jay Fields, covers this topic and may offer useful ...
6
Definitively, the testing code worth be treated with so much care as the production code for the next reasons
Testing code is an important documentation resource. Testing code speaks about the system we are working on. It tells stories about the business or the domain of the system. How components should behave, how the system behaves when components ...
5
If I understand correctly, your issue is with an implementation that most of the time "accidentally" fulfills the requirement. This is something that is very hard to test. Successful tests only prove that the implementation does the right thing in the specific test case, they cannot prove that it will always behave correctly.
You normally don't reach this ...
4
There is a widespread opinion that every test should test only one feature; the extreme version of this is that every test method may have only one assert. There is furthermore a common opinion that each feature should be tested only once; the extreme version of this is that every defect in your codebase should trip exactly one test.
I don't subscribe to ...
3
Part 1: Handling "accidental functionality" when writing tests
To answer your question, let's start at the beginning: with a failing test. I'm going to take as read the idea that you already understand the principles of TDD and use it. So I can use a completely contrived and pointless example to focus on the issues you are asking about, rather than "selling"...
2
I agree with your colleagues. DRY should be applied to tests as well as production code. The authors of test frameworks also agree by providing mechanisms (annotations, function decorators, etc) to execute a common setup method before each test method runs.
2
I think it depends on what you want to achieve. If its only a safety net to prevent regression, especially if it's solely from the outside (i.e. its treated as a closed black box that answers "Is it broken?") then the requirements are much the same as production code. Indeed there are production codes that black box test devices. If this is the case then the ...
1
DRY (don't repeat yourself) principle doesn't really apply to tests. This is because priorities change and your bottom line is that you want to ensure proper functioning of your program. In other words, don't be afraid to create a new test if you feel that the assertions for existing tests don't quite cover the new feature.
At the same time, I would be ...
1
It's very tempting to answer your question with "it depends", since that's the answer to many "should I...?" questions.
In this case, however, the answer is no. You should not create a sprint test plan. At least, not a formal one. The only test plan you need for a sprint is "verify that every completed story is well tested".
As a QA engineer on a scrum ...
1
Test functionality not implementation.
Testing implementation details kills refactoring. You can't change anything without breaking a test.
Correct headers, cookies, and token validity shouldn't be defined by the test. They should be defined by the code that creates them and uses them. What you test is if a user attempting to log in gets the response they ...
Only top voted, non community-wiki answers of a minimum length are eligible
