xunit test patterns refactoring test code phần 10 docx

793 Glossary direct outputs of the SUT. Direct outputs may consist of the return values of method or function calls, updated arguments passed by reference, exceptions raised by the SUT, or messages received on a message channel (e.g., MQ or JMS) from the SUT. document-driven development A development process that focuses on producing documents that describe how the code will be structured and then coding from those documents. Docu- ment-driven development is normally associated with “big design up front” (BDUF, also known as “waterfall”) software development. Contrast this with test-driven development, which focuses on producing working code one test at a time. domain layer The layer of a Layered Architecture [DDD, PEAA, WWW] that corresponds to the domain model. See Eric Evans’ book, Domain-Driven Design [DDD]. domain model A model of the problem domain that may form the basis of the object model in the business domain layer of a software application. See Eric Evans’ book, Domain-Driven Design [DDD]. DTO Short for the Data Transfer Object [CJ2EEP] design pattern. dynamic binding Deferring the decision about which piece of software to transfer control to until execution time. The same method name can be used to invoke different behavior (method bodies) based on the class of the object on which it is invoked; the latter class is determined only at execution time. Dynamic binding is the opposite of static binding; it is also called polymorphism (from the Latin, meaning “taking on many shapes”). EDD See example-driven development. Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com emergent design The opposite of BDUF (big design up front). Emergent design involves letting the right design be discovered as the software slowly evolves to pass one test at a time during test-driven development. endoscopic testing A testing technique pioneered by the authors of the original Mock Object paper [ET], which involves testing software from the inside. entity object An object that represents an entity concept from a domain. Entity objects typi- cally have a life cycle that is represented as their state. Contrast this with a service object, which has no single state. EJB Entity Beans are one example of an entity object. equivalence class A test condition identifi cation technique that reduces the number of tests required by grouping together inputs that should result in the same output or that should exercise the same logic in the system. This organization allows us to focus our tests on key boundary values at which the expected output changes. example-driven development (EDD) A reframing of the test-driven development process to focus on the “executable specifi cation” aspect of the tests. The act of providing examples is more intuitive to many people; it doesn’t carry the baggage of “testing” software that doesn’t yet exist. exercise SUT After the fi xture setup phase of testing, the test stimulates the system under test (SUT) logic that is to be tested. This phase of the testing process is called exercise SUT. Also known as: domain object Glossary 794 Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com expectation What a test expects the system under test (SUT) to have done. When we are using Mock Objects to verify the indirect outputs of the SUT, we load each Mock Object with the expected method calls (including the expected argu- ments); these are called the expectations. expected outcome The outcome that we verify after exercising the system under test (SUT). A Self-Checking Test verifi es the expected outcome using calls to Assertion Methods. exploratory testing Interactive testing of an application without a specifi c script in hand. The tester “explores” the system, making up theories about how it should behave based on what the application has already done and then testing those theories to see if they hold up. While there is no rigid plan, exploratory testing is a disciplined activity that is more likely to fi nd real bugs than rigidly scripted tests. eXtreme Programming An agile software development methodology that showcases pair programming, automated unit testing, and short iterations. factory A method, object, or class that exists to build other objects. false negative A situation in which a test passes even though the system under test (SUT) is not working properly. Such a test is said to give a false-negative indication or a “false pass.” See also: false positive. false positive A situation in which a test fails even though the system under test (SUT) is working properly. Such a test is said to give a false-positive indication or a Glossary 795 Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com “false failure.” The terminology comes from statistical science and relates to our attempt to calculate the probability of some observation error occurring. For example, in medicine we run tests to fi nd out if a medical condition is pres- ent; if it is, the test is “positive.” It is useful to know the probability that a test might indicate that a condition (such as diabetes) is present when it is not—that is, a false “positive.” If we think of software tests as a way of determining whether a condition (a particular defect or bug) is present, a test that reports a defect (a test failure or error) when it is not, in fact, present is giving us a false positive. See also: false negative. Wikipedia [Wp] has an extensive description under the topic “Type I and type II errors.” fault insertion test A kind of test in which a deliberate fault is introduced in one part of the sys- tem to verify that another part reacts to the error appropriately. Initially, the faults were related to hardware but the same concept is now applied to software faults as well. Replacing a depended-on component (DOC) with a Saboteur that throws an exception is an example of a software fault insertion test. feature A testable unit of functionality that can be built onto the evolving software sys- tem. In eXtreme Programming, a user story corresponds roughly to a feature. Fit test A test that uses the Fit testing framework; most commonly a customer test. fi xture See test fi xture (disambiguation). fi xture (Fit) In Fit, the Adapter [GOF] that interprets the Fit table and invokes methods on the system under test (SUT), thereby implementing a Data-Driven Test. For meanings in other contexts, see test fi xture (disambiguation), test fi xture (in xUnit), and test fi xture (in NUnit). Glossary 796 Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com fi xture holding class variable A class variable of a Testcase Class that is used to hold a reference to the test fi xture. It typically holds a reference to a Shared Fixture. fi xture holding instance variable An instance variable of a Testcase Object that is used to hold a reference to the test fi xture. It typically holds a reference to a Fresh Fixture that is set up using Implicit Setup. fi xture holding local variable A local variable of a Test Method that is used to hold a reference to the test fi x- ture. It typically holds a reference to a Fresh Fixture that is set up within the test method using In-line Setup or returned from Delegated Setup. fi xture setup Before the desired logic of the system under test (SUT) can be exercised, the pre- conditions of the test need to be set up. Collectively, all objects (and their states) are called the test fi xture (or test context), and the phase of the test that sets up the test fi xture is called fi xture setup. fi xture teardown After a test is run, the test fi xture that was built by the test should be destroyed. This phase of the test is called fi xture teardown. fl uent interface A style of object constructor API that results in easy-to-understand statements. The Confi guration Interface provided by the Mock Object toolkit JMock is an example of a fl uent interface. front door The public application programming interface (API) of a piece of software. Con- trast this with the back door. Glossary 797 Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com function pointer From Wikipedia [Wp]: “A function pointer is a type of pointer in C, C++, D, and other C-like programming languages. When dereferenced, a function pointer in- vokes a function, passing it zero or more arguments like a normal function.” functional test (common usage) A black-box test of the end-user functionality of an application. The agile com- munity is trying to avoid this usage of “functional test” because of the potential for confusion when talking about verifying functional (as opposed to nonfunctional or extra-functional properties) properties of a unit or component. This book uses the terms “customer test” and “acceptance test” for a functional test of the entire appli- cation and “unit test” for a functional test of an individual unit of the application. functional test (contrast with extra-functional test) A test that verifi es the functionality implemented by a piece of software. De- pending on the scope of the software, a functional test may be a customer test, a unit test, or a component test. In some circles a functional test is a customer test. This usage becomes con- fusing, however, when we talk about testing nonfunctional or extra-functional properties of the system under test (SUT). This book uses the terms “customer test” and “acceptance test” for a functional test of the entire application and “unit test” for a functional test of an individual unit of the application. garbage collection A mechanism that automatically recovers the memory used by any objects that are no longer accessible. Many modern object-oriented programming environ- ments provide garbage collection. global variable A variable that is global to a whole program. A global variable is accessible from anywhere within the program and never goes out of scope, although the memory to which it refers can be deallocated explicitly. green bar Many Graphical Test Runners portray the progress of the test run using a prog- ress bar. As long as all tests have passed, the bar stays green. When any tests fail, the indicator changes to a red bar. Also known as: procedure variable, delegate in .NET languages Glossary 798 Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com GUI Graphical user interface. happy path The “normal” path of execution through a use case or through the software that implements it; also known as the “sunny day” scenario. Nothing goes wrong, nothing out of the ordinary happens, and we swiftly and directly achieve the user’s or caller’s goal. Hollywood principle What directors in Hollywood tell aspiring actors at mass-casting calls: “Don’t call us; we’ll call you (if we want you).” In software, this concept is often called inversion of control (IOC). IDE Integrated development environment. An environment that provides tools to edit, compile, execute, and (typically) test code within a single development tool. incremental delivery A method of building and deploying a software system in stages and releasing the software as each stage, called an “increment,” is completed. This approach results in earlier delivery to the user of a working system, where the capabilities of the system increase over time. In agile methods, the increment of functionality is the feature or user story. Incremental delivery goes beyond iterative develop- ment and incremental development, however, by actually putting the functional- ity into production on a regular basis. This idea is summarized by the following mantra: “Deliver early, deliver often.” incremental development A method of building a software system in stages such that the functionality built to date can be tested before the next stage is started. This approach allows for the earlier delivery to the user of a working system, where the capabilities of the system increase over time (see incremental delivery). In agile methods, the incre- ment of functionality is the feature or user story. Incremental development goes beyond iterative development, however, in that it promises to produce working, Glossary 799 Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com testable, and potentially deployable software with every iteration. With incre- mental delivery, we also promise to “Deliver early, deliver often.” indirect input When the behavior of the system under test (SUT) is affected by the values returned by another component whose services it uses, we call those values the indirect in- puts of the SUT. Indirect inputs may consist of actual return values of functions, updated (out) parameters of procedures or subroutines, and any errors or excep- tions raised by the depended-on component (DOC). Testing of the SUT behavior with indirect inputs requires the appropriate control point on the “back side” of the SUT. We often use a Test Stub to inject the indirect inputs into the SUT. indirect output When the behavior of the system under test (SUT) includes actions that cannot be observed through the public application programming interface (API) of the SUT but that are seen or experienced by other systems or application compo- nents, we call those actions the indirect outputs of the SUT. Indirect outputs may consist of method or function calls to another component, messages sent on a message channel (e.g., MQ or JMS), and records inserted into a database or written to a fi le. Verifi cation of the indirect output behaviors of the SUT requires the use of appropriate observation points on the “back side” of the SUT. Mock Objects are often used to implement the observation point by intercepting the indirect outputs of the SUT and comparing them to the expected values. See also: outgoing interface. inner class A class in Java that is defi ned inside another class. Anonymous inner classes are defi ned inside a method, whereas inner classes are defi ned outside a method. In- ner classes are often used when defi ning Hard-Coded Test Doubles. instance method A method that is associated with an object rather than the class of the object. An instance method is accessible only from within or via an instance of the class. It is typically used to access information that is expected to differ from one instance to another. Also known as: outgoing interface 800 Glossary Also known as: member variable Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com The exact syntax used to access an instance method varies from language to language. The most common syntax is objectReference.methodName(). When referenced from within other methods on the object, some languages require an explicit reference to the object (e.g., this.methodName() or self methodName); other languages simply assume that any unqualifi ed references to methods are references to instance methods. instance variable A variable that is associated with an object rather than the class of object. An instance variable is accessible only from within or via an instance of the class. It is typically used to access information that is expected to differ from one instance to another. interaction point A point at which a test interacts with the system under test (SUT). An interac- tion point can be either a control point or an observation point. interface In general, a fully abstract class that defi nes only the public methods that all im- plementers of the interface must provide. In Java, an interface is a type defi nition that does not provide any implementation. In most single-inheritance languages, a class may implement any number of interfaces, even though it can extend (subclass) only one other class. inversion of control (IOC) A control paradigm that distinguishes software frameworks from “toolkits” or components. The framework calls the software plug-in (rather than the reverse). In the real world, inversion of control is often called the Hollywood principle. With the advent of automated unit testing, a class of framework known as an inversion of control framework has sprung up specifi cally to simplify the re- placement of depended-on components (DOCs) with Test Doubles. IOC See inversion of control. Also known as: member function Glossary 801 Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com iterative development A method of building a software system using time-boxed “iterations.” Each iteration is planned and then executed. At the end of the “time box,” the status of all the work is reviewed and the next iteration is planned. The strict time- boxing prevents “runaway development,” where the state of the system is never assessed because nothing is ever fi nished. Unlike incremental development, itera- tive development does not require working software to be delivered at the end of each iteration. layer-crossing test A test that either sets up the fi xture or verifi es the outcome using Back Door Manipulation, which involves using a “back door” of the system under test (SUT) such as a database. Contrast this with a round-trip test. legacy software In the test-driven development community, any software that does not have a Safety Net of Fully Automated Tests. liveware The people who use our software. They are usually assumed to be much more intelligent than either the software or the hardware but they can also be rather unpredictable. local variable A variable that is associated with a block of code rather than an object or class. A local variable is accessible only from within the code block; it goes out of scope when the block of code returns to its caller. manual test A test that is executed by a person interacting with the system under test (SUT). The user may be following some sort of “test script” (not to be confused with a Scripted Test) or doing ad hoc or exploratory testing. Also known as: wetware, mushware Glossary 802 Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com [...]... concepts of test context and Testcase Class can be confusing This book uses test fixture” to mean “the pre-conditions of the test (also known as the test context) and Testcase Class to mean “the class that contains the Test Methods and any code needed to set up the test context.” test fixture (in xUnit) Also known as: test context In xUnit: All the things we need to have in place to run a test and expect... system under test (SUT) is supposed to do (Tests as Documentation) or as part of a test maintenance or software development activity test result A test or test suite can be run many times, each time yielding a different test result test run A test or test suite can be run many times, each time yielding a different test result Some commercial test automation tools record the results of each test run for... case test automater The person or project role that is responsible for building the tests Sometimes a “subject matter expert” may be responsible for coming up with the tests to be automated by the test automater test case Usually a synonym for test. ” In xUnit, it may also refer to a Testcase Class, which is actually a Test Suite Factory as well as a place to put a set of related Test Methods test code. .. to debug a test error than a test failure because the cause of the problem tends to be much more local to where the test error occurs Compare with test failure and test success test failure When a test is run and the actual outcome does not match the expected outcome Compare with test error and test success test- first development A development process that entails writing and automating unit tests before... applied at the unit test or customer test level, depending on which tests we have chosen to automate test fixture (disambiguation) In generic xUnit: All the things we need to have in place to run a test and expect a particular outcome The test fixture comprises the pre-conditions of the test; that is, it is the “before” picture of the SUT and its context See also: test fixture (in xUnit) and test context In... characteristic called emergent design) See also: storytest-driven development test driver A person doing test- driven development test driving The act of doing test- driven development test error When a test is run, an error that keeps the test from running to completion The error may be explicitly raised or thrown by the system under test (SUT) or by the test itself, or it may be thrown by the runtime system... whatever reason If the test maintainer is doing the enhancements by writing tests first, he or she is also a test driver test package In languages that provide packages or namespaces, a package or name that exists for the purpose of hosting Testcase Classes test reader Anyone who has reason to read tests, including a test maintainer or test driver This individual may be reading the tests primarily for... attribute [TestFixture] to the class that hosts the Test Methods Some members of the xUnit family assume that an instance of the Testcase Class “is a” test context; NUnit is a good example This interpretation assumes we are using the Testcase Class per Fixture approach to organizing the tests When we choose to use a different way of organizing the tests, such as Testcase Class per Class or Testcase Class... not doing enough of Test debt arises when we do not write all of the necessary tests As a result, we have “unprotected code in that the code could break without causing any tests to fail test- driven bug fixing A way of fixing bugs that entails writing and automating unit tests that reproduce each bug before we begin debugging the code and fixing the bug; the bug-fixing extension of test- driven development... the corresponding units begins Test- first development ensures that the responsibilities of each software unit are well understood before that unit is coded Unlike test- driven development, test- first development merely says that the tests are written before the production code; it does not imply that the production code is made to work one test at a time (emergent design) Test- first 814 Glossary Simpo PDF . related Test Methods. test code Code written specifi cally to test other code (either production or other test code) . test condition A particular behavior of the system under test (SUT) that we. test automater. test case Usually a synonym for test. ” In xUnit, it may also refer to a Testcase Class, which is actually a Test Suite Factory as well as a place to put a set of related Test. “customer test and “acceptance test for a functional test of the entire appli- cation and “unit test for a functional test of an individual unit of the application. functional test (contrast