Development

From Things and Stuff Wiki
Jump to: navigation, search

Things and Stuff Wiki - an organically evolving knowledge base wiki containing topic outlines, descriptions and breadcrumbs, with links to sites, systems, software, manuals, organisations, people, articles, guides, slides, papers, books, comments, screencasts, webcasts, scratchpads, and more. table of contents for navigation on long pages. see About for further information. / et / em

See also Organisation#Collaboration, Process

Engineering



  • https://en.wikipedia.org/wiki/Functional_specification - (also, functional spec, specs, functional specifications document (FSD), functional requirements specification, or Program specification) in systems engineering and software development is the documentation that describes the requested behavior of an engineering system. The documentation typically describes what is needed by the system user as well as requested properties of inputs and outputs (e.g. of the software system). A functional specification is the more technical response onto a matching requirements document, e.g. the Product Requirement Document "PRD". Thus it picks up the results of the requirements analysis stage. On more complex systems multiple levels of functional specifications will typically nest to each other, e.g. on the system level, on the module level and on the level of technical details.












  • Formal Methods of Software Design - using mathematics to write error-free programs. The mathematics needed is not complicated; it's just boolean algebra. The word "formal" means the use of a formal language, so that the program logic can be machine checked. Our compilers already tell us if we make a syntax error, or a type error, and they tell us what and where the error is. Formal methods take the next step, telling us if we make a logic error, and they tell us what and where the error is. And they tell us this as we make the error, not after the program is finished. It is good to get any program correct while writing it, rather than waiting for bug reports from users. It is absolutely essential for programs that lives will depend on.



  1. Do you use source control?
  2. Can you make a build in one step?
  3. Do you make daily builds?
  4. Do you have a bug database?
  5. Do you fix bugs before writing new code?
  6. Do you have an up-to-date schedule?
  7. Do you have a spec?
  8. Do programmers have quiet working conditions?
  9. Do you use the best tools money can buy?
  10. Do you have testers?
  11. Do new candidates write code during their interview?
  12. Do you do hallway usability testing?

tef:

  1. "Programmers who know they will make mistakes
  2. "Programmers who think they will not make mistakes"


  • Methods & Tools - Software development magazine: software testing, project management, Agile, Scrum, UML, programming, requirements




  • https://en.wikipedia.org/wiki/Build_automation - the act of scripting or automating a wide variety of tasks that software developers do in their day-to-day activities including things like: compiling computer source code into binary code, packaging binary code, running tests

deploying to production systems, creating documentation and/or release notes



People

Tools

See also WebDev#Authoring, Vim, Git, JS tools, *nix, etc.



  • Start-up Tools - Start-ups are always short on time: here are some tools that can save you time and avoid reinventing the wheel. This list is focused on technical tools to save development time.

Continuous process

  • https://en.wikipedia.org/wiki/Continuous_design - a software development practice of creating and modifying the design of a system as it is developed, rather than specifying the system completely before development starts, (as in the waterfall model) or in bursts at the beginning of each iteration (as in the iterative model). Also called "evolutionary design" or "incremental design", continuous design was popularized by extreme programming. Continuous design also uses test driven development and refactoring.
  • https://en.wikipedia.org/wiki/Continuous_integration - the practice, in software engineering, of merging all developer working copies with a shared mainline several times a day. It was first named and proposed by Grady Booch in his method, who did not advocate integrating several times a day however. It was adopted as part of extreme programming (XP), which did advocate multiple integrations a day, perhaps as many as tens a day. The main aim of CI is to prevent integration problems, referred to as "integration hell" in early descriptions of XP. CI isn't universally accepted as an improvement over frequent integration, so it is important to distinguish between the two as there is disagreement about the virtues of each

"Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly."


  • https://en.wikipedia.org/wiki/Continuous_delivery - a design practice used in software development to automate and improve the process of software delivery. Techniques such as automated testing, continuous integration and continuous deployment allow software to be developed to a high standard and easily packaged and deployed to test environments, resulting in the ability to rapidly, reliably and repeatedly push out enhancements and bug fixes to customers at low risk and with minimal manual overhead. The technique was one of the assumptions of extreme programming but at an enterprise level has developed into a discipline of its own, with job descriptions for roles such as "buildmaster" calling for CD skills as mandatory.



Jenkins

StriderCD

  • Strider is an Open Source Continuous Deployment / Continuous Integration platform. It is written in Node.JS / JavaScript and uses MongoDB as a backing store. BSD license. A focus on Continuous Deployment rather than just Continuous Integration: Designed to be easy to install & setup. Deployable & usable on Heroku free plan. Intended for deployment on private infrastructure. An emphasis on extensibility. Plugins are powerful, easy to write and simple to install. Out-of-the-box support for projects written in Node.JS, Python (generic and Django/Pyramid) and Selenium/Sauce Labs tests. Commercial support, consulting & hosting available

Git based

Services

  • https://travis-ci.org/ a hosted, distributed continuous integration service used to build and test projects hosted at GitHub. The software is also available as an open source download on GitHub, although its developers do not currently recommend it for on-premise use for closed projects

Testing

  • Errbit - The open source, self-hosted error catcher

Build


  • https://waf.io - The Waf framework is somewhat different from traditional build systems in the sense that it does not provide support for a specific language. Rather, the focus is to support the major usecases encountered when working on a software project. As such, it is essentially a library of components that are suitable for use in a build system, with an emphasis on extensibility. Although the default distribution contains various plugins for several programming languages and different tools (c, d, ocaml, java, etc), it is by no means a frozen product. Creating new extensions is both a standard and a recommended practice.

Source control

  • https://en.wikipedia.org/wiki/Version_control - A component of software configuration management, version control, also known as revision control or source control, is the management of changes to documents, computer programs, large web sites, and other collections of information. Changes are usually identified by a number or letter code, termed the "revision number", "revision level", or simply "revision". For example, an initial set of files is "revision 1". When the first change is made, the resulting set is "revision 2", and so on. Each revision is associated with a timestamp and the person making the change. Revisions can be compared, restored, and with some types of files, merged.

The need for a logical way to organize and control revisions has existed for almost as long as writing has existed, but revision control became much more important, and complicated, when the era of computing began. The numbering of book editions and of specification revisions are examples that date back to the print-only era. Today, the most capable (as well as complex) revision control systems are those used in software development, where a team of people may change the same files.

Version control systems (VCS) most commonly run as stand-alone applications, but revision control is also embedded in various types of software such as word processors and spreadsheets, e.g., Google Docs and Sheets and in various content management systems, e.g., Wikipedia's Page history. Revision control allows for the ability to revert a document to a previous revision, which is critical for allowing editors to track each other's edits, correct mistakes, and defend against vandalism and spamming. Software tools for revision control are essential for the organization of multi-developer projects.

Software

SCCS / CSSC

  • http://www.gnu.org/software/cssc/ - CSSC is the GNU Project's replacement for SCCS. SCCS is a proprietary suite of tools which is provided with most commercial versions of Unix. The purpose behind CSSC is to provide a work-alike for SCCS which can be used on the various Free versions of Unix.

SCCS was the only major form of source code control on Unix platforms for many years, until RCS came along. SCCS was an effective method for small projects, but these days is less popular, particularly for projects involving large numbers of files. A fair amount of old software is still in SCCS form, and CSSC is designed to retrieve that software. Once retrieved, it is highly recommended to bring the source under the control of more modern source code control systems, such as git or Apache Subversion.

RCS

  • GNU RCS - The Revision Control System (RCS) manages multiple revisions of files. RCS automates the storing, retrieval, logging, identification, and merging of revisions. RCS is useful for text that is revised frequently, including source code, programs, documentation, graphics, papers, and form letters.

RCS design is an improvement from its predecessor Source Code Control System (SCCS) (see GNU CSSC). The improvements include an easier user interface and improved storage of versions for faster retrieval. RCS improves performance by storing an entire copy of the most recent version and then stores reverse differences (called "deltas"). RCS uses GNU Diffutils to find the differences between versions.

CVS

SVN

Bazaar

Distributed

BitKeeper

1998 / 2000

Mercurial

2005


Git

2005

See Git

Fossil

2006

Utils

  • webcheckout - check out repositories referenced on a web page
  • Gource is a software version control visualization tool.

Management

  • Kallithea - project of Software Freedom Conservancy, is a GPLv3'd, Free Software source code management system that supports two leading version control systems, Mercurial and Git, and has a web interface that is easy to use for users and admins. You can install Kallithea on your own server and host repositories for the version control system of your choice. [13]
  • Gerrit - provides web based code review and repository management for the Git version control system.

IDE

  • Lamdu - aims to create a next-generation live programming environment that radically improves the programming experience.





Debugging

To merge with *nix#Debugging / move to Computing


  • BCC is a toolkit for creating efficient kernel tracing and manipulation programs, and includes several useful tools and examples. It makes use of eBPF (Extended Berkeley Packet Filters), a new feature that was first added to Linux 3.15. Much of what BCC uses requires Linux 4.1 and above. [16]


DTrace

Testing


People

Articles

Books

Information

  • Association for Software Testing - an international non-profit professional association with members in over 50 countries. AST is dedicated and strives to build a testing community that views the role of testing as skilled, relevant, and essential to the production of faster, better, and less expensive software products. We value a scientific approach to developing and evaluating techniques, processes, and tools. We believe that a self-aware, self-critical attitude is essential to understanding and assessing the impact of new ideas on the practice of testing.

Concepts

  • https://en.wikipedia.org/wiki/Test_strategy - an outline that describes the testing approach of the software development cycle. It is created to inform project managers, testers, and developers about some key issues of the testing process. This includes the testing objective, methods of testing new functions, total time and resources required for the project, and the testing environment.

Test strategies describe how the product risks of the stakeholders are mitigated at the test-level, which types of test are to be performed, and which entry and exit criteria apply. They are created based on development design documents. System design documents are primarily used and occasionally, conceptual design documents may be referred to. Design documents describe the functionality of the software to be enabled in the upcoming release. For every stage of development design, a corresponding test strategy should be created to test the new feature sets.

  • https://en.wikipedia.org/wiki/Test_plan - a document detailing a systematic approach to testing a system such as a machine or software. The plan typically contains a detailed understanding of the eventual workflow.
  • https://en.wikipedia.org/wiki/Test_suite - less commonly known as a validation suite, is a collection of test cases that are intended to be used to test a software program to show that it has some specified set of behaviours. A test suite often contains detailed instructions or goals for each collection of test cases and information on the system configuration to be used during testing. A group of test cases may also contain prerequisite states or steps, and descriptions of the following tests.
  • https://en.wikipedia.org/wiki/Test_case - a set of conditions or variables under which a tester will determine whether an application, software system or one of its features is working as it was originally established for it to do. The mechanism for determining whether a software program or system has passed or failed such a test is known as a test oracle. In some settings, an oracle could be a requirement or use case, while in others it could be a heuristic. It may take many test cases to determine that a software program or system is considered sufficiently scrutinized to be released. Test cases are often referred to as test scripts, particularly when written - when they are usually collected into test suites.
  • https://en.wikipedia.org/wiki/Test_harness - or automated test framework is a collection of software and test data configured to test a program unit by running it under varying conditions and monitoring its behavior and outputs. It has two main parts: the test execution engine and the test script repository. Test harnesses allow for the automation of tests. They can call functions with supplied parameters and print out and compare the results to the desired value. The test harness is a hook to the developed code, which can be tested using an automation framework.
  • https://stackoverflow.com/questions/11625351/what-is-test-harness


Varieties

  • https://en.wikipedia.org/wiki/Static_testing - a form of software testing where the software isn't actually used. checks mainly for the sanity of the code, algorithm, or document. It is primarily checking of the code and/or manually reviewing the code or document to find errors. This type of testing can be used by the developer who wrote the code, in isolation. Code reviews, inspections and Software walkthroughs are also used.
  • https://en.wikipedia.org/wiki/Black-box_testing - examines the functionality of an application (e.g. what the software does) without peering into its internal structures or workings. This method of test can be applied to virtually every level of software testing: unit, integration, system and acceptance. It typically comprises most if not all higher level testing, but can also dominate unit testing as well.


  • https://en.wikipedia.org/wiki/Dynamic_testing - dynamic analysis refers to the examination of the physical response from the system to variables that are not constant and change with time. In dynamic testing the software must actually be compiled and run. It involves working with the software, giving input values and checking if the output is as expected by executing specific test cases which can be done manually or with the use of an automated process. This is in contrast to static testing. Unit tests, integration tests, system tests and acceptance tests utilize dynamic testing.


  • https://en.wikipedia.org/wiki/Fuzz_testing - involves providing invalid, unexpected, or random data to the inputs of a computer program. The program is then monitored for exceptions such as crashes, or failing built-in code assertions or for finding potential memory leaks. Fuzzing is commonly used to test for security problems in software or computer systems. It is a form of random testing which has been used for testing hardware or software.



  • https://en.wikipedia.org/wiki/Exploratory_testing - an approach to software testing that is concisely described as simultaneous learning, test design and test execution. Cem Kaner, who coined the term in 1983, now defines exploratory testing as "a style of software testing that emphasizes the personal freedom and responsibility of the individual tester to continually optimize the quality of his/her work by treating test-related learning, test design, test execution, and test result interpretation as mutually supportive activities that run in parallel throughout the project."

While the software is being tested, the tester learns things that together with experience and creativity generates new good tests to run. Exploratory testing is often thought of as a black box testing technique. Instead, those who have studied it consider it a test approach that can be applied to any test technique, at any stage in the development process. The key is not the test technique nor the item being tested or reviewed; the key is the cognitive engagement of the tester, and the tester's responsibility for managing his or her time.

  • https://en.wikipedia.org/wiki/Session-based_testing - a software test method that aims to combine accountability and exploratory testing to provide rapid defect discovery, creative on-the-fly test design, management control and metrics reporting. The method can also be used in conjunction with scenario testing. Session-based testing was developed in 2000 by Jonathan and James Bach. Session-based testing can be used to introduce measurement and control to an immature test process and can form a foundation for significant improvements in productivity and error detection. Session-based testing can offer benefits when formal requirements are not present, incomplete, or changing rapidly.
  • https://en.wikipedia.org/wiki/Error_guessing - a test method in which test cases used to find bugs in programs are established based on experience in prior testing. The scope of test cases usually rely on the software tester involved, who uses past experience and intuition to determine what situations commonly cause software failure, or may cause errors to appear.
  • https://en.wikipedia.org/wiki/Scenario_testing - a software testing activity that uses scenarios: hypothetical stories to help the tester work through a complex problem or test system. The ideal scenario test is a credible, complex, compelling or motivating story the outcome of which is easy to evaluate. These tests are usually different from test cases in that test cases are single steps whereas scenarios cover a number of steps. Kaner coined the phrase scenario test by October 2003. He commented that one of the most difficult aspects of testing was maintaining step-by-step test cases along with their expected results. His paper attempted to find a way to reduce the re-work of complicated written tests and incorporate the ease of use cases.
  • https://en.wikipedia.org/wiki/Scenario_(computing)
  • https://en.wikipedia.org/wiki/Functional_testing - a quality assurance (QA) process and a type of black box testing that bases its test cases on the specifications of the software component under test. Functions are tested by feeding them input and examining the output, and internal program structure is rarely considered (not like in white-box testing). Functional testing differs from system testing in that functional testing "verifies a program by checking it against ... design document(s) or specification(s)", while system testing "validate[s] a program by checking it against the published user or system requirements"
  • https://en.wikipedia.org/wiki/Non-functional_testing - testing of a software application for its non-functional requirements. The names of many non-functional tests are often used interchangeably because of the overlap in scope between various non-functional requirements. For example, software performance is a broad term that includes many specific requirements like reliability and scalability.

Agile;

Unit testing

  • https://en.wikipedia.org/wiki/Unit_testing - testing 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. 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. Unit tests are short code fragments created by programmers or occasionally by white box testers during the development process. Ideally, each test case is independent from the others. Substitutes such as method stubs, mock objects, fakes, and test harnesses can be used to assist testing a module in isolation. Unit tests are typically written and run by software developers to ensure that code meets its design and behaves as intended.
  • http://c2.com/cgi/wiki?UnitTest

TDD

BDD

  • Behavior Driven Development - BDD evolved by incorporating what works from Test Driven Development, Agile User Stories, Domain Driven Design and XP with an emphasis on product behavior testing over unit testing. Project stakeholders and team members focus on the problem domain and develop a common language for expressing a product's desired behavior as stories and acceptance test criteria. Developers can then map the stories and criteria on their test code to verify application behavior and report results in the same common language.
  • easyb is a behavior driven development framework for the Java platform. By using a specification based Domain Specific Language, easyb aims to enable executable, yet readable documentation.

DDD

ACC

  • Test Analytics is a Google web application that allows rapid generation of a project's ACC model -- an alterative to a test plan that is faster to create and of more practical value. This decomposition of the product allows a easy way to visualize project risk across project capabilities. In addition, Test Analytics supports importing quality signals -- tests, code changes, and bugs -- to quantify risk and map it across your project's model. This gives a bird's eye view of the risk associated with all areas of your project, and a way to assess what portions of your project need additional testing.

ACC consists of three different parts that define your system under test: Attributes, Components, and Capabilities. An easy way to think of each of these elements is by relating them to a part of speech relating to your project.

  • Attributes (adjectives of the system) are qualities and characteristics that promote the product and distinguish it from the competition; examples are "Fast", "Secure", "Stable", and "Elegant". A product manager could have a hand in narrowing down the list of Attributes for the system.
  • Components (nouns of the system) are building blocks that together constitute the system in question. Some examples of Components are "Firmware", "Printing", and "File System" for an operating system project, or "Database", "Cart", and "Product Browser" for an online shopping site.
  • Capabilities (verbs of the system) describe the abilities of a particular Component in order to satisfy the Attributes of the system. An example Capability for a shopping site could be "Processes monetary transactions using HTTPS". You can see that this could be a Capability of the "Cart" component when trying to meet the "Secure" Attribute. The most important aspect of Capabilities is that they are testable.

Further

  • https://en.wikipedia.org/wiki/Acceptance_test-driven_development - a development methodology based on communication between the business customers, the developers, and the testers. ATDD encompasses many of the same practices as Specification by Example, Behavior Driven Development (BDD), Example-Driven Development (EDD), and Story Test-Driven Development (SDD). All these processes aid developers and testers in understanding the customer’s needs prior to implementation and allow customers to be able to converse in their own domain language. ATDD is closely related to Test-Driven Development. It differs by the emphasis on developer-tester-business customer collaboration. ATDD encompasses acceptance testing, but highlights writing acceptance tests before developers begin coding.

Videos

Basics;

RBCS INC;

to check later;

Events

Software

See also WebDev#Testing

xUnit

  • https://en.wikipedia.org/wiki/xUnit - the collective name for several unit testing frameworks that derive their structure and functionality from Smalltalk's SUnit. SUnit, designed by Kent Beck in 1998, was written in a highly-structured object-oriented style, which lent easily to contemporary languages such as Java and C#. Following its introduction in Smalltalk the framework was ported to Java by Beck and Erich Gamma and gained wide popularity, eventually gaining ground in the majority of programming languages in current use.
  • JUnit is a simple framework to write repeatable tests. It is an instance of the xUnit architecture for unit testing frameworks.
  • TestDox creates simple documentation from the method names in JUnit test cases.

TestNG

Fit

FitNesse

JSUnit

  • JsUnit is a Unit Testing framework for client-side (in-browser) JavaScript. It is essentially a port of JUnit to JavaScript. Also included is a platform for automating the execution of tests on multiple browsers and mutiple machines running different OSs. Its development began in January 2001, not actively developed or supported.

Waitr

  • Watir - pronounced water, is an open-source (BSD) family of Ruby libraries for automating web browsers. It allows you to write tests that are easy to read and maintain. It is simple and flexible. Watir drives browsers the same way people do. It clicks links, fills in forms, presses buttons. Watir also checks results, such as whether expected text appears on the page. Watir is a family of Ruby libraries but it supports your app no matter what technology it is developed in. Whilst Watir supports only Internet Explorer on Windows, Watir-WebDriver supports Chrome, Firefox, Internet Explorer, Opera and also running in headless mode (HTMLUnit). Like other programming languages, Ruby gives you the power to connect to databases, read data files and spreadsheets, export XML, and structure your code as reusable libraries.
  • WatiN - Web Application Testing In .Net. Inspired by Watir development of WatiN started in December 2005 to make a similar kind of Web Application Testing possible for the .Net languages

Selenium

  • Selenium is a portable software testing framework for web applications. Selenium provides a record/playback tool for authoring tests without learning a test scripting language (Selenium IDE). It also provides a test domain-specific language (Selenese) to write tests in a number of popular programming languages, including C#, Java, Groovy, Perl, PHP, Python and Ruby. The tests can then be run against most modern web browsers.
Videos
Selenium 1 (Remote Control)
  • Bromine is an open source QA tool that uses selenium RC as its testing engine.
Selenium 2 (WebDriver)
  • http://webdriver.io/ WebdriverJS is an open source testing utility for nodejs. It makes it possible to write super easy selenium tests with Javascript in your favorite BDD or TDD test framework. Even Cucumber tests are supported. It basically sends requests to a Selenium server via the WebDriver Wire Protocol and handles with its response. These requests are wraped in useful commands, which provides callbacks to test several aspects of your site in an automated way.
  • Selendroid is a test automation framework which drives off the UI of Android native and hybrid applications (apps) and the mobile web. Tests are written using the Selenium 2 client API - that's it!


Grid
IDE
Builder
Mobile
  • Selendroid is a test automation framework which drives off the UI of Android native and hybrid applications (apps) and the mobile web. Tests are written using the Selenium 2 client API - that's it!
  • ios-driver - Test any IOS native, hybrid, or mobile web application using Selenium / WebDriver.
Other
  • Galen is a test framework originally designed for testing layout of web applications but is also a great tool for functional testing. When it comes to testing a responsive layout it works in a following way: Open a page in browser, Resize it to specified size, Test the layout according to user-defined specs. It uses Selenium for interacting with elements on page and getting their locations and dimensions.
Services

Cucumber

  • Cucumber lets software development teams describe how software should behave in plain text. The text is written in a business-readable domain-specific language and serves as documentation, automated tests and development-aid - all rolled into one format. Cucumber works with Ruby, Java, .NET, Flex or web applications written in any language. Cucumber also supports more succinct tests in tables - similar to what FIT does. Dig around in the examples and documentation to learn more about Cucumber tables. Cucumber is the RSpec Story Runner done right.

Jasmine

  • Jasmine is a Behavior Driven Development testing framework for JavaScript. It does not rely on browsers, DOM, or any JavaScript framework. Thus it's suited for websites, Node.js projects, or anywhere that JavaScript can run.

TestLink

Other

  • Concordion - an open source tool for writing automated acceptance tests in Java (and .NET, Python, Scala, and Ruby).
  • Test Recorder - The purpose of the application is to generate code compatible with several applications, including WatiN (Web Application Testing In .NET), Celerity, and WatiR.
  • Window Licker - A framework for the test-driven development of Java systems through the GUI.
  • RSpec is testing tool for the Ruby programming language. Born under the banner of Behaviour-Driven Development, it is designed to make Test-Driven Development a productive and enjoyable experience
  • HtmlUnit is a "GUI-Less browser for Java programs". It models HTML documents and provides an API that allows you to invoke pages, fill out forms, click links, etc... just like you do in your "normal" browser. HtmlUnit is not a generic unit testing framework. It is specifically a way to simulate a browser for testing purposes and is intended to be used within another testing framework such as JUnit or TestNG.
  • JWebUnit is a Java-based testing framework for web applications. It wraps existing testing frameworks such as HtmlUnit and Selenium with a unified, simple testing interface to allow you to quickly test the correctness of your web applications.
  • Webrat lets you quickly write expressive and robust acceptance tests for a Ruby web application.
  • Windmill is a web testing tool designed to let you painlessly automate and debug your web application.

Originating at the Open Source Applications Foundation Windmill was built to help QA keep up with the rapid release cycles of the Chandler Server Web UI (Cosmo) project.

  • CubicTest is a graphical Eclipse plug-in for writing Selenium and Watir tests. It makes tests faster and easier to write, and provides abstractions to make tests more robust and reusable. CubicTest's test editor is centered around pages/states and transitions between these pages/states. The model is intuitive for both Ajax and traditional web applications and supports most user interaction types.
  • Robot Framework is a generic test automation framework for acceptance testing and acceptance test-driven development (ATDD). It has easy-to-use tabular test data syntax and it utilizes the keyword-driven testing approach. Its testing capabilities can be extended by test libraries implemented either with Python or Java, and users can create new higher-level keywords from existing ones using the same syntax that is used for creating test cases.


  • Marionette is an automation driver. It can remotely drive either the UI or the internal JavaScript of a program built on the Gecko platform, such as Firefox or Firefox OS. Marionette runs as a server on your test machine, allowing you to connect to that server and remotely drive tests and send commands. Its goal is to replicate what Selenium does for the browser: to enable the tester to have the ability to send commands to a remote test machine. Marionette shares much of the same API as Selenium/WebDriver, and makes writing tests easy. You have the API to drive user actions like page navigation and element clicking, but also the ability to execute arbitrary JavaScript scripts, allowing for a greater variety of tests.




  • TUT is a small and portable unit test framework for C++.
  • UnitTest++ is a lightweight unit testing framework for C++.
  • Bandit is a framework for C++11 that wants to make working with unit tests a pleasant experience.
  • Snowhouse is a stand alone assertion framework for C++. It was originally developed as part of Igloo and has been extracted to be usable in other contexts.
  • cute - C++ unit test executor
  • Catch - A modern, C++-native, header-only, framework for unit-tests, TDD and BDD [25]





Qualifications

Crowdsourced

Documentation


UI markup

UML

XUL

  • XUL (/ˈzuːl/ zool), which stands for XML User Interface Language, is a user interface markup language that is developed by the Mozilla Project. XUL is implemented as an XML dialect; it allows for graphical user interfaces to be written in a similar manner to Web pages.