Loading ...
Sorry, an error occurred while loading the content.

Testing a web-stack (angular+REST), From: [XP] TDD and kinds of test

Expand Messages
  • Jonas Andersson
    Done that mistake as well :) First and only time so far that we ve had to drop a complete testing suite. :/ A stack with Angular + REST looks great from the
    Message 1 of 3 , Apr 4, 2014
    • 0 Attachment

      Done that mistake as well :) First and only time so far that we've had to drop a complete testing suite. :/

      A stack with Angular + REST looks great from the perspective that you can test the back-end and front-end separately. 

      In theory:
      Use TDD+BDD on backend, including REST-API-tests.
      Use TDD+BDD on front-end, using REST-mocking.

      Anyone tried this? If so, was it productive?

      // Jonas


      On 3 April 2014 23:06, Phlip <phlip2005@...> wrote:
       

      > In practice ATDD and BDD ..

      Just a note here - another HUGE industry fallacy, repeated at all
      levels, is that BDD, for "functional testing", mean "integration tests
      using klutzy screen-driver AND a declarative language that even
      consultants can read & write."

      Put another way, junior Rails programmers by the truckload these days
      are taught -

      - tdd the model with the unit test folder, and call it BDD bc we test
      with RSpec

      - tdd the controllers & not the view with the functional test folder,
      with template rendering turned off

      - tdd the HTML or JS, even at the trivial level of "what color tag do
      we template in?" using ONLY
      * Cucumber BDD runner, using ...
      * Gherkhin notation, driving ...
      * Capybara (a webrat offspring), running Selenium on your Chrome
      browser!, plugged into ...
      * a real HTTP server, running your Rails app in a 4th
      environment, operating on ...
      * a complete batch of data records copied in each time, using ...
      * a ton of mocks for everything that "just stopped working bc we
      added that feature & didn't want to add it to the test", AND ...
      * a couple of ridiculous hack gems that keep your test VM in
      memory forever so it's not so incredibly slow.

      A more fragile stack could not be imagined. Oh, yeah, and it's all
      open source, getting out of sync with each other every season or so.

      (the correct way to test HTML views, btw, is render their templates &
      test most of the view using assert_xpath, and yes I'm obviously
      recovering from an experience, here...)

      All of that teaching is wrong, false, the opposite of true, and only
      damages the BDD movement. Good luck getting rid of that stupid meme
      because it's unbelievably damaging, and entirely tempting using
      today's tools!!


    • Prasad Narravula
      we are doing it now. AngularJS comes with a mock to stub out HTTP calls, making test setup relatively easy. For frontend, we use Karma/Jasmine. For backend
      Message 2 of 3 , Apr 4, 2014
      • 0 Attachment

         we are doing it now.  AngularJS comes with a mock to stub out HTTP calls, making test setup relatively easy. 
        For frontend, we use Karma/Jasmine.  
        For backend (C#), we use Machine Specifications.

        We also write few browser automation tests using Protractor, another angular based framework. This requires a integration test environment.

        When it comes to test scope in AngularJS,  at one end, You could test drive behaviors, covering all MVC elements with stubs to calls crossing the boundary, on other end, you could write unit tests covering single elements such as controllers mocking out rest of the things.


        Thanks,
        Prasad Narravula




        To: extremeprogramming@yahoogroups.com
        From: jonananas@...
        Date: Fri, 4 Apr 2014 13:04:40 +0200
        Subject: Testing a web-stack (angular+REST), From: [XP] TDD and kinds of test

         


        Done that mistake as well :) First and only time so far that we've had to drop a complete testing suite. :/

        A stack with Angular + REST looks great from the perspective that you can test the back-end and front-end separately. 

        In theory:
        Use TDD+BDD on backend, including REST-API-tests.
        Use TDD+BDD on front-end, using REST-mocking.

        Anyone tried this? If so, was it productive?

        // Jonas


        On 3 April 2014 23:06, Phlip <phlip2005@...> wrote:
         
        > In practice ATDD and BDD ..

        Just a note here - another HUGE industry fallacy, repeated at all
        levels, is that BDD, for "functional testing", mean "integration tests
        using klutzy screen-driver AND a declarative language that even
        consultants can read & write."

        Put another way, junior Rails programmers by the truckload these days
        are taught -

        - tdd the model with the unit test folder, and call it BDD bc we test
        with RSpec

        - tdd the controllers & not the view with the functional test folder,
        with template rendering turned off

        - tdd the HTML or JS, even at the trivial level of "what color tag do
        we template in?" using ONLY
        * Cucumber BDD runner, using ...
        * Gherkhin notation, driving ...
        * Capybara (a webrat offspring), running Selenium on your Chrome
        browser!, plugged into ...
        * a real HTTP server, running your Rails app in a 4th
        environment, operating on ...
        * a complete batch of data records copied in each time, using ...
        * a ton of mocks for everything that "just stopped working bc we
        added that feature & didn't want to add it to the test", AND ...
        * a couple of ridiculous hack gems that keep your test VM in
        memory forever so it's not so incredibly slow.

        A more fragile stack could not be imagined. Oh, yeah, and it's all
        open source, getting out of sync with each other every season or so.

        (the correct way to test HTML views, btw, is render their templates &
        test most of the view using assert_xpath, and yes I'm obviously
        recovering from an experience, here...)

        All of that teaching is wrong, false, the opposite of true, and only
        damages the BDD movement. Good luck getting rid of that stupid meme
        because it's unbelievably damaging, and entirely tempting using
        today's tools!!



      • thierry henrio
        ... Yes No, or it depends™ You can not put definite words on your knowledge I believe that test driven development on X is a learning process on X Given you
        Message 3 of 3 , Apr 4, 2014
        • 0 Attachment

          In theory:
          Use TDD+BDD on backend, including REST-API-tests.
          Use TDD+BDD on front-end, using REST-mocking.

          Anyone tried this? If so, was it productive?

          Yes
          No, or it depends™

          You can not put definite words on your knowledge

          I believe that test driven development on X is a learning process on X

          Given you do not know X
          And you look back at the tests you wrote on X 6 months later
          When you feel they are good
          Then you have not learn enough
          .

          It does not depends, for me

          And I delete code that I made, in front of the very face of my peers
          And I tell them it is not good code

          And I delete code from my peers, in front of them
          And I tell them it is not good code

          Oh yes, sometimes, ones tell me he's uncomfortable when I do it

          Then I write another test
          Any test

          And I tell them what I learned and why the test ( or the code ) I deleted is because I did not understood what I ( he ) did
          And I tell them it is ok to do so

          Oh yes, sometimes, ones tell me he's uncomfortable when I do it

          Serious, Thierry
        Your message has been successfully submitted and would be delivered to recipients shortly.