Unit testing

In computer programming, unit testing is a method by which individual units of source code, sets of one or more computer program modules together with associated control data, usage procedures, and operating procedures are tested to determine if they are fit for use.[1] Intuitively, one can view a unit as the smallest testable part of an application. In procedural programming, a unit could be an entire module, but it is more commonly an individual function or procedure. In object-oriented programming, a unit is often an entire interface, such as a class, but could be an individual method.[2] Unit tests are short code fragments[3] created by programmers or occasionally by white box testers during the development process. Ideally, each test case is independent from the others. Benefits[edit] The goal of unit testing is to isolate each part of the program and show that the individual parts are correct.[1] A unit test provides a strict, written contract that the piece of code must satisfy.

Test-driven development Software design using test cases Test-driven development (TDD) is a software development process relying on software requirements being converted to test cases before software is fully developed, and tracking all software development by repeatedly testing the software against all test cases. This is as opposed to software being developed first and test cases created later. Software engineer Kent Beck, who is credited with having developed or "rediscovered"[1] the technique, stated in 2003 that TDD encourages simple designs and inspires confidence.[2] Test-driven development is related to the test-first programming concepts of extreme programming, begun in 1999,[3] but more recently has created more general interest in its own right.[4] Programmers also apply the concept to improving and debugging legacy code developed with older techniques.[5] Test-driven development cycle[edit] The following sequence is based on the book Test-Driven Development by Example:[2] 1. 2. 3. 4. 5. Repeat

Mock object In object-oriented programming, mock objects are simulated objects that mimic the behavior of real objects in controlled ways. A programmer typically creates a mock object to test the behavior of some other object, in much the same way that a car designer uses a crash test dummy to simulate the dynamic behavior of a human in vehicle impacts. Reasons for use[edit] In a unit test, mock objects can simulate the behavior of complex, real objects and are therefore useful when a real object is impractical or impossible to incorporate into a unit test. If the real object: supplies non-deterministic results (e.g., the current time or the current temperature);has states that are difficult to create or reproduce (e.g., a network error);is slow (e.g., a complete database, which would have to be initialized before the test);does not yet exist or may change behavior;would have to include information and methods exclusively for testing purposes (and not for its actual task). Technical details[edit]

Behavior Driven Development In software engineering, behavior-driven development (abbreviated BDD) is a software development process based on test-driven development (TDD).[1][2] Behavior-driven development combines the general techniques and principles of TDD with ideas from domain-driven design and object-oriented analysis and design to provide software developers and business analysts with shared tools and a shared process to collaborate on software development,[1][3] with the aim of delivering "software that matters".[4] Although BDD is principally an idea about how software development should be managed by both business interests and technical insight, the practice of BDD does assume the use of specialized software tools to support the development process.[2] Although these tools are often developed specifically for use in BDD projects, they can be seen as specialized forms of the tooling that supports test-driven development. History[edit] Principles of BDD[edit] Behavioral specifications[edit] See Also[edit]

Dependency injection There are three common forms of dependency injection: setter-, interface- and constructor-based injection, where the responsibility of injecting the dependency lies upon the client, the service or the constructor method respectively. Overview[edit] Implementation of dependency injection is often identical to that of the strategy pattern, but while the strategy pattern is intended for dependencies to be interchangeable throughout an object's lifetime, in dependency injection only a single instance of a dependency is used.[citation needed] Application frameworks such as Spring, Guice, Glassfish HK2, and Microsoft Managed Extensibility Framework (MEF) support dependency injection. Advantages[edit] Disadvantages[edit] Examples[edit] Without dependency injection[edit] Dependency injection is an alternative technique to initialize the member variable than explicitly creating a service object as shown above. Three types of dependency injection[edit] Other types[edit] Constructor injection[edit]

FitNesse Coupling (computer programming) Conceptual model of coupling Coupling can be "low" (also "loose" and "weak") or "high" (also "tight" and "strong"). Some types of coupling, in order of highest to lowest coupling, are as follows: A module here refers to a subroutine of any kind, i.e. a set of one or more statements having a name and preferably its own set of variable names. Content coupling (high) Content coupling (also known as Pathological coupling) occurs when one module modifies or relies on the internal workings of another module (e.g., accessing local data of another module). Therefore changing the way the second module produces data (location, type, timing) will lead to changing the dependent module. Common coupling Common coupling (also known as Global coupling) occurs when two modules share the same global data (e.g., a global variable). Changing the shared resource implies changing all the modules using it. External coupling Control coupling Stamp coupling (Data-structured coupling) Data coupling Message coupling (low)

specs2 @ GitHub Specify your software using both text and Scala code class HelloWorldSpec extends Specification { def is = s2""" This is a specification for the 'Hello world' string The 'Hello world' string should contain 11 characters $e1 start with 'Hello' $e2 end with 'world' $e3 """ def e1 = "Hello world" must haveSize(11) def e2 = "Hello world" must startWith("Hello") def e3 = "Hello world" must endWith("world") } Use different styles of specifications /** This is the "Unit" style for specifications */class HelloWorldSpec extends Specification { "This is a specification for the 'Hello world' string".txt "The 'Hello world' string should" >> { "contain 11 characters" >> { "Hello world" must haveSize(11) } "start with 'Hello'" >> { "Hello world" must startWith("Hello") } "end with 'world'" >> { "Hello world" must endWith("world") } }} Document your APIs with compiler-checked examples Manage contexts for integration testing

Modular programming "Code Factoring" redirects here. It is not to be confused with code refactoring. Modular programming is a software design technique that emphasizes separating the functionality of a program into independent, interchangeable modules, such that each contains everything necessary to execute only one aspect of the desired functionality.[1] Terminology[edit] Language support[edit] Modular programming can be performed even where the programming language lacks explicit syntactic features to support named modules. Key aspects[edit] With modular programming, concerns are separated such that modules perform logically discrete functions, interacting through well-defined interfaces. This makes modular designed systems, if built correctly, far more reusable than a traditional monolithic design, since all (or many) of these modules may then be reused (without change) in other projects. History[edit] See also[edit] Notes[edit] References[edit] Jump up ^ Seif Haridi; Nils Franzén. "7.