{"id":765,"date":"2011-12-09T10:56:00","date_gmt":"2011-12-09T10:56:00","guid":{"rendered":"http:\/\/www.javacodegeeks.com\/2012\/10\/some-definitions-testing-techniques-9.html"},"modified":"2012-10-21T20:53:24","modified_gmt":"2012-10-21T20:53:24","slug":"some-definitions-testing-techniques-9","status":"publish","type":"post","link":"https:\/\/www.javacodegeeks.com\/2011\/12\/some-definitions-testing-techniques-9.html","title":{"rendered":"Some Definitions – Testing Techniques 9"},"content":{"rendered":"
I think that I\u2019m coming to the end of my series of blogs on testing techniques, and it feels like it\u2019s been along haul. One of the things that has become clearer to me is that approaches to testing are still in their infancy and as such are a definite source of contention or discussion amongst developers – and that\u2019s a good thing.<\/p>\n

I suspect that we are at a point in the history of our profession where the discipline of writing tests is only just gaining ground and will one day be common place and taught as part of elementary programming classes (1). Today\u2019s blog provides a summary of the of the terms used in my previous blogs in this series.<\/p>\n

Unit Tests<\/strong>
\nI covered the definition of a unit test in part two of this series of blogs, giving the views of Shane Warden, who in his book The Art of Agile Development<\/i> states that unit tests should run at a rate of \u201chundreds per second\u201d; Michael Feathers, who in his book Working Effectively<\/i> with Legacy Code<\/i> states that a unit test is not a unit test if:<\/p>\n

    \n
  1. It talks to a database.<\/li>\n
  2. It communicates across a network.<\/li>\n
  3. It touches the file system.<\/li>\n
  4. You have to do special things to your environment (such as editing configuration files) to run it.<\/li>\n<\/ol>\n

    I also quoted Roy Osherove, who in his book The Art Of Unit Testing<\/span><\/a><\/i> sums up a good unit test as: “an automated piece of code that invokes the method or class being tested and then checks some assumptions about the logical behaviour of that method or class. A unit test is almost always written using a unit testing framework. It can be written easily and runs quickly. It’s fully automated, trustworthy, readable and maintainable”.<\/p>\n

    Unit tests can be summed up using the FIRST<\/span><\/a> acronym: Fast, Independent, Repeatable, Self Validating and Timely.<\/p>\n

    When to Use Unit Tests<\/strong>
    \nUnit tests are the bread and butter of testing. If you employ Test Driven Development, TDD, then you write failing tests before you write your production code. If you don\u2019t use TDD, then at least write your tests at the same time as your production code i.e. write a method and then write its tests. This technique doesn\u2019t involve the paradigm shift that accompanies TDD, but it\u2019s much better than writing tests after you\u2019ve written all the code, which is usually considered tedious by developers. There should be one test for every scenario, which translated into plain English means every path through your code: both sides of every if<\/span> statement and every case of a switch<\/span> statement. In short, every project should have hundreds of Unit Tests and you should have the confidence that if you change a part of the code then you won\u2019t break something.

    <\/div> <\/div><\/p>\n

    Stubs<\/strong>
    \nStubs are used to isolate an object under test from the rest of the system. They are objects that are injected into your object to replace real objects in test situations. Martin Fowler defines stubs, in his essay Mocks Aren\u2019t Stubs as:<\/p>\n

    \u201cStubs provide canned answers to calls made during the test, usually not responding at all to anything outside what’s programmed in for the test. Stubs may also record information about calls, such as an email gateway stub that remembers the messages it ‘sent’, or maybe only how many messages it ‘sent’\u201d<\/p>\n

    …whilst a similar definition, taken from The Art of Unit Testing<\/i><\/span><\/a> is: <\/p>\n

    \u201cA stub is a controllable replacement for an existing dependency (or collaborator<\/i>) in the system. By using stub, you can test your code without using the dependency directly.\u201d<\/p>\n

    Mocks<\/strong>
    \nMocks are replacement objects used to imitate, or mock, the behaviour or roles of production objects. This really means checking that an object under test calls methods on a mock object as expected with the test failing if it doesn\u2019t; hence, you\u2019re asserting on the correctness of method calls and the execution path through your code, rather than, in the case of a regular unit test, the return value of the method under test.<\/p>\n

    Integration Tests
    \nIntegration tests are the opposite of unit tests. The idea behind integration tests is to prove that your objects collaborate with each other and the system around them. To paraphrase Michael Feathers, integration tests CAN<\/strong>:<\/p>\n

      \n
    1. talk to a database.<\/li>\n
    2. communicate across a network.<\/li>\n
    3. touch the file system.<\/li>\n
    4. require you to do special things to your environment (such as editing configuration files) to run it.<\/li>\n<\/ol>\n

      Roy Osherove in the Art of Unit Testing states that an \u201cintegration test means testing two or more or more dependent software modules together as a group\u201d. For me this constrains the definition a little too much after all, in testing objects in a single module you can access a database or file system whilst figuring out if your objects can collaborate.<\/p>\n

      In projects I\u2019ve previously worked on, there\u2019s usually been a module specifically written to hold integration tests. This is because integration tests are less numerous than unit tests (perhaps at a ratio of 1:10) and, by virtue of the fact that they access their environment, are usually substantially slower and therefore corralling all integration tests into their own Maven module means that they don\u2019t have to run every time you build a module, speeding up build and development time.<\/p>\n

      End to End Integration Tests<\/strong>
      \nI\u2019ve covered End to End tests in detail in the second blog in this series, so to summarise, they can be defined as a special case of integration tests in that the test commences at, or just behind, a system boundary and executes through all layers of the system. Where the system boundary, or just behind the system boundary is a matter for debate. In terms of a Spring MVC app, there\u2019s no reason why an end to end test shouldn\u2019t start at your controller code ignoring the browser and dispatcher servlet. After all, I suspect that the Guys at Spring have tested their code thoroughly, so why should you waste time testing it? Also, testing what the front end looks like s a whole different kettle of fish.<\/p>\n

      (1) I often suspect that testing techniques are not actually taught in collages and universities – but I\u2019ve no evidence of this. If there are any academics out there who can tell me that unit testing is taught, encouraged and an integral part of their Computer Science Degree courses then I\u2019d be happy to hear from them.<\/p>\n

      Reference: <\/i><\/strong>Some Definitions – Testing Techniques 9<\/a> from our JCG partner<\/a>  Roger Hughes at the Captain Debug’s Blog<\/a>.<\/p>\n

      Related Articles :<\/i><\/strong><\/p>\n