Stack Exchange Network

Stack Exchange network consists of 175 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Visit Stack Exchange

New answers tagged

7

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


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


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


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.


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


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


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


0

I advise creating an end to end test which uses a client to connect to your api as a user would. You want to be able to point these tests at your live api and ensure its working. There are always implementation details that can go wrong with the hosting layer, such as ports, firewalls, caching etc which unit tests on your service layer wont pick up


Top 50 recent answers are included