Should testers write unit tests/cucumber tests?


our company has been using the Agile methodology for some time now and as the company matures we take on more tenets of how it works, so this is all great stuff.

However, we take part in “3 amigos” sessions with a developer and BA, off the back of which we then write up the acceptance criteria based on the details in the user story using the gherkin language. Now, we aren’t yet at the stage where we are running automated tests linked to these scenarios(eg in Cucumber); they more act as a guide so that the dev has more detailed criteria to work off, and the tester can subsequently carry out exploratory tests based on the acceptance criteria or write more detailed test cases

When we are in a position to automate the acceptance criteria tests(using the gherkin language) my question is…would writing these tests generally be a testers role, a dual role, a developers role? I’m just trying to understand how the two piece together.

The above ties in to a question I have(which is hopefully linked) in that would testers normally get involved in writing unit tests or is this a development activity? Now, I’m more than comfortable in getting my hands dirty and coding(specifically around writing automated tests using Selenium WebDriver) but I just have difficulty getting my head around where the paths separate!

As always, thanks for reading and I look forward to any feedback



Typically you’ll see automated tests described as a pyramid (google: “automated test pyramid”).

Where unit tests, being the cheapest and fastest to run are the most plentiful are at the bottom. Integration tests are more expensive to write and are less granular so they go in the middle. UI level e2e automation take the longest to run and write and thusly sits at the top of the pyramid.

True unit tests are extremely granular and are almost always written by the developer either while they are coding the feature or very soon after. Integration tests will have the more complex components written by developers who will also write some testing but you’ll also see testers writing at this level. Finally, UI / e2e testing will take longer and mostly be written by testing groups but you can of course have developers writing these as well.


Ask yourself why you’re writing automated acceptance tests and you’ll find your answer. If the automation you write is to be well thought out, only writing tests that have value that meet the cost and only automating what lends itself to automation, with a proper vision of purpose then good testers are a great resource for designing them (if not writing them). If you’re using them to do BDD your programmers are likely to benefit more as BDD is a way to guide development towards described behaviours, so they should have a say in how they are written. Those can be disposable, so they don’t have to be part of a maintainable, purpose-driven, high-value automation suite.

I think whatever you’re doing collaboration is likely to get you a better result, but you need to know why your process looks like it does before you decide who does what. The tool is just a tool, who uses it depends on how you want to use the tool and who benefits from its use; and when you know that you can make process and ownership more clear.