> Non-technical employees can't really write them either so they be revised by a developer This is the part I could never buy into either. You cannot escape th

> Non-technical employees can't really write them either so they be revised by a developer This is the part I could never buy into either. You cannot escape that writing tests is the same thing as programming (you need to break the problem down into steps, formalise what you want to check, use abstractions) so non-programmers aren't good at writing tests without rigorous training. Non-programmers tend to need a lot of help even describing what they want in plain English as well because they just aren't used to thinking like programmers. I've worked with non-technical people for years who still don't understand that "it's not working" isn't enough information to go on. As for overhead, it might make sense if you're working on one project in a single language for a long time but the setup and configuration overhead has been significant when I've tried BDD tests. I'd rather just use descriptive function names in tests as then you can take advantage of autocompletion, automated refactoring, jump to definition shortcuts, static checking, language features etc.