I am trying to apply BDD and DDD together to a new project The problem I am having at the moment can be summed up by the following quote (taken from here: https://www.infoq.com/news/2015/02/bdd-ddd):

"The approach for most BDD practitioners is to test outside–in by testing every scenario through the user interface, UI. In contrast, what DDD practitioners care most about is the domain core which for them is hidden behind a slow and fragile UI and they therefore tend to work middle–out, starting with the domain core and not until the implementation of the core is stable enough, an implementation of a UI on top of the core is done."

The article then says:

"In order to bring BDD and DDD practices together the two techniques needs to be combined and Kudryashov does this by first removing the UI then running tests through the domain"

Idea 1

Say I have a Step Definition like this:

[When(@"I calculate eligibility for Loans")]
public void WhenICalculateEligibilityForLoans()
    _actualLoans = _eligibilityController.CalculateEligibility(_person, _availableLoans.ToList();

Notice that the Step Definition calls a controller from the UI. This means that I have to wait until the UI is ready before I can run this test. In fact the Step Definition will not even compile until the UI is developed (at the end of the sprint). Is this normal?

Idea 2

Change the step definition to this:

[When(@"I calculate eligibility for Loans")]
public void WhenICalculateEligibilityForLoans()
    _actualLoans = _eligibilityDomainObject.CalculateEligibility(_person, _availableLoans.ToList();

Idea 3

Change the Step Definitions as I work through the sprint. This means that idea 2 will be used when I develop the domain model and idea 1 when I develop the UI.

Are any of my ideas valid or is there another idea?

  • 1
    Why do you think of a controller as "from the UI"? – candied_orange Mar 21 '18 at 11:15
  • 1
    @CandiedOrange, MVC is a UI technology. That is my thinking. Is there something wrong with that thinking? What do you understand as the UI? – w0051977 Mar 21 '18 at 11:18
  • Well since your question centers on testing going through or not going through the UI we had better all understand what you mean by UI. I think of only the code needed to show a GUI or a CLI or some such. I don't think of controllers. I wouldn't consider tests that talk to controllers as "testing through the user interface". The difference you're showing here is only semantic. Other then a name change, it's the same API. – candied_orange Mar 21 '18 at 11:40
  • @CandiedOrange, my definition of UI is how I interpreted its meaning from the linked article. If you interpret it differently then do let me know. – w0051977 Mar 21 '18 at 11:46
  • 1
    I think it would help to mention that a typical responsibility of a Controller to decouple the actual UI code from the rest of the application. So, by that definition, code in the Controller is not UI code. – MetaFight Mar 21 '18 at 12:45

Testing a controller directly doesn't make much sense to me. You have a limited amount of things to test at this level, and the majority are verifying the proper domain methods were called, and the correct view(s) were returned. Calling the controller directly means you aren't really testing that the UI is wired up correctly. To really test a UI you need to go a level higher and interact with views, this assures you that the UI actually works and the proper views were returned.

Testing that CalculateEligibility returns correct results should only be done on the domain object. Your UI can assume values it receives are always correct if it passes valid values, otherwise you are duplicating your testing.

  • I have separate Unit Tests and Specifications. The Unit Tests will test the Domain object. Should the Specifications concentrate on the Domain Object as well? – w0051977 Mar 21 '18 at 12: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.