Following on from my previous question and the comments under the accepted answer: One Acceptance Test project per layer or one Acceptance Test project per Bounded Context

I have done a lot of reading into BDD recently as I try to decide whether it is applicable to a project. I have come across the term Honeycomb (https://skillsmatter.com/skillscasts/10933-sub-second-tdd-with-a-dash-of-honey), which seem to suggest that "end to end" can mean different things depending on whether you are interested in speed or reliability. In one case it may mean the UI (most outer layer) to the Domain Model (most inner layer) and in another case it may just mean the domain model on its own. I cannot find any more information about Honeycomb.

Have I understood "end to end" correctly? My team is currently developing a Domain Model for an application. We will not be writing the other layers e.g. application service; UI etc. Is it normal to use BDD to test one layer of the application in isolation? i.e. in this case end to end is from Domain Model to Domain Model rather than UI to Domain Model.

The reason I ask is because I believe it will help us to engage with business analysts and QA. However, I don't want to abuse BDD.


There is a lot of fuzziness around the terms unit test, integration test, and end-to-end test. Some think they overlap and are interchangeable. To some extent this is true.

A major source of confusion comes when people couple the terms to how their implemented. This is wrong. Not every test you write using jUnit, or some such, is a unit test. Using a particular framework or coding style doesn't make it a certain kind of test. It's about what you test. And to a large extent, how what you test performs.

enter image description here

Unit tests can be atomic. That is they test the smallest thing possible to test. Some people only use unit to mean atomic. Which is fine but others set the boundary at speed. They have performance requirements that they insist all their unit tests conform to. Personally I like this second take on the meaning of unit test.

Integration tests seem to overlap this second idea of what a unit test is. After all if two atomic things are involved they must integrate in some way. Others see integration tests as happening across architectural boundaries. These tests don't have the same performance constraints as the unit tests. Again I'm in the second camp.

End-to-end tests in almost every case I've experienced them involve taking a use case from start to finish. Again that overlaps, at least part of, the definition of an integration test. It doesn't have to involve a UI since one might not exist but it might. Especially if you're doing manual testing. Automated testing that involves a UI is notoriously difficult, mostly because UI's are very subject to change. A good practice is to remove all testable logic from the UI so automated testing can drive the application through the API the UI uses as if it was the UI.

There are competing mindsets here that cause the different interpretations. I don't like the idea that the tools I use dictate what I'm doing. I don't like the idea that the structure involved dictates what I'm doing. I do like distinguishing what I'm doing based the needs I'm fulfilling. One of those needs is speed.

Hopefully that way of defining these terms will catch on.

  • Thanks. +1 for: "I don't like the idea that the tools I use dictate what I'm doing." and "involve taking a use case from start to finish.". – w0051977 Mar 11 '18 at 20:52
  • If the use case/user story is centred around the core only then I guess the core is the only layer in the "end to end". Have I understood that correctly from your answer? – w0051977 Mar 11 '18 at 20:53
  • I did say start to finish. That usually involves more than just the core. But like I said with the UI the more you involve the more unstable things become. For example an end to end test for a use case where you print should involve a printer. Sure you can configure a virtual printer to speed up testing but it's not really end to end if there is no real printer involved. But that's slower and wastes paper. I'd have both tests and only rarely perform the end-to-end one. – candied_orange Mar 11 '18 at 21:03
  • Thanks, do you know of any code, which shows how to have both tests (I use the word both from your previous comment) in C# using interfaces? The hyperlink in my post shows how to do it using Node.js. I assume I would need some sort of factory. – w0051977 Mar 11 '18 at 22:39
  • To my mind, you are attempting to conflate two distinct things: a functional unit and an atomic unit. Unit tests fit firmly in the former camp. If I run almost my entire console-based app with zero side effects though a test, then it's a functional unit (its result is the same value every time). But what that test is testing is easily broken into sub parts, so it's not atomic. So I'd suggest that unit tests should almost never be atomic. – David Arno Mar 11 '18 at 23:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.