发表新帖
发表新帖

Developing UI in JavaScript using TDD Principles

前端 未结
关注
7 1903
有刺的猬
有刺的猬 2020-12-22 22:54

I\'ve had a lot of trouble trying to come up with the best way to properly follow TDD principles while developing UI in JavaScript. What\'s the best way to go about this?

相关标签:
7条回答
  • 说谎
    2020-12-22 23:15

    I've done some TDD with Javascript in the past, and what I had to do was make the distinction between Unit and Integration tests. Selenium will test your overall site, with the output from the server, its post backs, ajax calls, all of that. But for unit testing, none of that is important.

    What you want is just the UI you are going to be interacting with, and your script. The tool you'll use for this is basically JsUnit, which takes an HTML document, with some Javascript functions on the page and executes them in the context of the page. So what you'll be doing is including the Stubbed out HTML on the page with your functions. From there,you can test the interaction of your script with the UI components in the isolated unit of the mocked HTML, your script, and your tests.

    That may be a bit confusing so lets see if we can do a little test. Lets to some TDD to assume that after a component is loaded, a list of elements is colored based on the content of the LI.

    tests.html

    <html>
<head>
<script src="jsunit.js"></script>
<script src="mootools.js"></script>
<script src="yourcontrol.js"></script>
</head>
<body>
    <ul id="mockList">
        <li>red</li>
        <li>green</li>
    </ul>   
</body>
<script>
    function testListColor() {
        assertNotEqual( $$("#mockList li")[0].getStyle("background-color", "red") );

        var colorInst = new ColorCtrl( "mockList" );

        assertEqual( $$("#mockList li")[0].getStyle("background-color", "red") );
    }
</script>


</html>

    Obviously TDD is a multi-step process, so for our control, we'll need multiple examples.

    yourcontrol.js (step1)

    function ColorCtrl( id ) {
 /* Fail! */    
}

    yourcontrol.js (step2)

    function ColorCtrl( id ) {
    $$("#mockList li").forEach(function(item, index) {
        item.setStyle("backgrond-color", item.getText());
    });
    /* Success! */
}

    You can probably see the pain point here, you have to keep your mock HTML here on the page in sync with the structure of what your server controls will be. But it does get you a nice system for TDD'ing with JavaScript.

    0 讨论(0)
  • 我寻月下人不归
    2020-12-22 23:19

    See also: JavaScript unit test tools for TDD

    0 讨论(0)
  • 感动是毒
    2020-12-22 23:23

    I'm just about to start doing Javascript TDD on a new project I am working on. My current plan is to use qunit to do the unit testing. While developing the tests can be run by simply refreshing the test page in a browser.

    For continuous integration (and ensuring the tests run in all browsers), I will use Selenium to automatically load the test harness in each browser, and read the result. These tests will be run on every checkin to source control.

    I am also going to use JSCoverage to get code coverage analysis of the tests. This will also be automated with Selenium.

    I'm currently in the middle of setting this up. I'll update this answer with more exact details once I have the setup hammered out.

    Testing tools:

    • qunit
    • JSCoverage
    • Selenium
    0 讨论(0)
  • 花落未央
    2020-12-22 23:24

    I've found the MVP architecture to be very suitable for writing testable UIs. Your Presenter and Model classes can simply be 100% unit tested. You only have to worry about the View (which should be a dumb, thin layer only that fires events to the Presenter) for UI testing (with Selenium etc.)

    Note that in the I'm talking about using MVP entirely in the UI context, without necessarily crossing to the server-side. Your UI can have its own Presenter and Model that lives entirely on the client-side. The Presenter drives the UI interaction/validation etc. logic while the Model keeps state information and provides a portal to the backend (where you can have a separate Model).

    You should also take a look at the Presenter First TDD technique.

    0 讨论(0)
  • 误落风尘
    2020-12-22 23:25

    I've never successfully TDDed UI code. The closest we came was indeed to separate UI code as much as possible from the application logic. This is one reason why the model-view-controller pattern is useful - the model and controller can be TDDed without much trouble and without getting too complicated.

    In my experience, the view was always left for our user-acceptance tests (we wrote web applications and our UATs used Java's HttpUnit). However, at this level it's really an integration test, without the test-in-isolation property we desire with TDD. Due to this setup, we had to write our controller/model tests/code first, then the UI and corresponding UAT. However, in the Swing GUI code I've been writing lately, I've been writing the GUI code first with stubs to explore my design of the front end, before adding to the controller/model/API. YMMV here though.

    So to reiterate, the only advice I can give is what you already seem to suspect - separate your UI code from your logic as much as possible and TDD them.

    0 讨论(0)
  • 执笔经年
    2020-12-22 23:25

    This is the primary reason I switched to the Google Web Toolkit ... I develop and test in Java and have a reasonable expectation that the compiled JavaScript will function properly on a variety of browsers. Since TDD is primarily a unit testing function, most of the project can be developed and tested before compilation and deployment.

    Integration and Functional test suites verify that the resulting code is functioning as expected after it's deployed to a test server.

    0 讨论(0)
 看不清?
提交回复
热议问题