Javascript – How to do BDD for CRUD

bddcrudhtmljavascript

I want to understand how Behavior-Driven Development (BDD) can be applied to building CRUD applications.

I have read a lot on the subject but I just don't get how I'm supposed to apply it. I learn best by example, so I built a mini CRUD application and I would like for someone to complete it by adding the tests. The application is a simple registration form. The user fill the form with his email, then the server save it in the database.

Q1. What behavior am I supposed to test?

Q2. What part should I test?

Obviously, I want my user to be able to register their email. So is it that the behavior I'm supposed to test? Also, do I test the UI? Do I test that the email is really in the database after the registration? And, how do I test all that?

https://jsfiddle.net/cufxn40o/26/

Html

<h1>Registration Form</h1>
Email
<input type="text" id="email" />
<button type="button" onclick="client.register();">
  Register
</button>
<div id="error"></div>

Javascript

/**
 * The client represents the code that runs in the browser
 */
var client = {
    register: function () {
    var email = document.getElementById('email').value;
    ajaxPost(server.register, {email: email}, function(result){
        if(result.error){
        document.getElementById('error').innerHTML = result.error;
      } else {
        document.getElementById('error').innerHTML = '';
        alert('Registration successful!');
      }
    });
  }
};

/**
 * The server represents the code that runs on the server
 */
var server = {
    /**
   * The only method the client can call
   */ 
    register: function (model) {
    var error = server.validate(model);
    if(error) return {error: error};
    else
    {
        server.saveRegistration(model.email);
      return {success: true};
    }
  },

  validate:  function (model) {
    if(!model.email) return 'An email is required';
    if(!framework.isValidEmail(model.email)) return 'This is not a valid email';
    if(server.emailExists(model.email)) return 'This email already exist';
  },

  emailExists: function(email){
    return SqlDatabase.some(x => x === email);
  },

  saveRegistration: function(email){
    SqlDatabase.push(email);
  }
};

/**
 * This is a real SQL database!
 */ 
var SqlDatabase = [];


/**
 * THe framework used by the server code.
 * This code was not created by me
 */ 
var framework = {
    isValidEmail: function(email) {
    return email && email.indexOf('@') !== -1;
  }
};

/**
 * A utility function to simulate an ajax request in this example
 * You can ignore it
 */
function ajaxPost(url, data, callback){
    var result = url(data);
  callback(result);
}

Best Answer

I built a mini CRUD application and I would like for someone to complete it by adding the tests

If you are doing BDD you should have defined the required behaviour first. then written the tests, then built the app.

SO the behaviour would presumably be something like:

When a user is on the register page
and types their email in the email field
and presses the register button
then the email should be saved to the database

You can then automate each line, say with webdriver, put it all together into a test, running in a BDD framework (Cucumber?), which loads the page, inputs the email, clicks the button and checks the database for the entry. If it's present the test passes.

Now you can write your webpage. as you add functionality each line of the behaviour will turn green.

When the app is complete all your tests are green.

The supposed benefits of the approach are that..

  1. Because the Behaviour is written in 'plain english' the customer can write the tests.
  2. Because the tests are running against the actual app, UI instead of unit once they are green the app matches the spec, which was written by the customer, so it impossible to have bugs right!??
  3. Because each step of the test turns red or green you know how much more you have to do before you have completed all the time.

Obviously there are a few flaws in there. I would say the approach boils down to the 'plain english', multi-line test description of UI tests.

Which isn't a bad thing at all to have, but isn't drastically different from other approaches either.

Related Topic