Skip to content

Instantly share code, notes, and snippets.

@mcintyre321

mcintyre321/gist:08b086153f17471b08ba

Last active September 24, 2020 15:03
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save mcintyre321/08b086153f17471b08ba to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save mcintyre321/08b086153f17471b08ba to your computer and use it in GitHub Desktop.
Download ZIP

Revisions

  1. mcintyre321 revised this gist Sep 24, 2020. 1 changed file with 0 additions and 1 deletion.
    1 change: 0 additions & 1 deletion gistfile1.md
    View file
    Original file line number Diff line number Diff line change
    @@ -23,7 +23,6 @@ Development methodologies
    - Gherkin - a syntax for writing human readable tests (Given, When, Then).
    - inside-out tests - where you start tests anywhere, often testing internal types and classes
    - outside-in tests - where you only test via the public interface of the system under test
    - test-per-class - a strict form of inside out testings, where unit corresponds to a single class

    Properties of tests

  2. mcintyre321 revised this gist Sep 24, 2020. 1 changed file with 4 additions and 14 deletions.
    18 changes: 4 additions & 14 deletions gistfile1.md
    View file
    Original file line number Diff line number Diff line change
    @@ -14,26 +14,16 @@ Uses of tests
    - Regression test - a test that ensures existing features are working. Actually all acceptance tests
    - Smoke test - run after releasem, verifies a major feature is working, typically an end to end test

    Descriptive styles

    - Behavioural test (BDD terminology)
    - a test that is described in terms of a terms of desired behavior of the unit
    - not to be confused with Mockist tests
    - typically human (product owner/qa) readable
    - should not become obsolete when an implementation is altered (although may require refactoring)
    - Classicaly described test
    - Requirement is expressed using the developers own words and understanding of the requirements
    - Descriptive method names are often used
    - often meaning of code is expressed using code constructs
    - refactoring of codebase can cloud the meaning (e.g. a method name may be renamed to match the code inside it more closely, loosing the original expression of the requirement)

    Development processes
    Development methodologies

    - Spike & stabilise - where code is developed and tests written after the fact
    - TDD - a development process where tests are written before writing code0
    - BDD - a development process where *behavioural* tests are written before writing code, ideally with input from PO/QA
    - ATDD (acceptance test driven development) - a bit like BDD, where agreed acceptance criteria, typically written using Gherkin (Given, When, Then) are used to drive the implementation
    - Gherkin - a syntax for writing human readable tests (Given, When, Then).
    - inside-out tests - where you start tests anywhere, often testing internal types and classes
    - outside-in tests - where you only test via the public interface of the system under test
    - test-per-class - a strict form of inside out testings, where unit corresponds to a single class

    Properties of tests

  3. mcintyre321 revised this gist Aug 7, 2018. 1 changed file with 5 additions and 6 deletions.
    11 changes: 5 additions & 6 deletions gistfile1.md
    View file
    Original file line number Diff line number Diff line change
    @@ -14,25 +14,25 @@ Uses of tests
    - Regression test - a test that ensures existing features are working. Actually all acceptance tests
    - Smoke test - run after releasem, verifies a major feature is working, typically an end to end test

    Descriptive styles
    Descriptive styles

    - Behavioural test (BDD terminology)
    - a test that is described in terms of a terms of desired behavior of the unit
    - not to be confused with Mockist tests
    - typically human (product owner/qa) readable
    - should not become obsolete when an implementation is altered (although may require refactoring)
    - Non-behavioural test
    - a test where is it not clear to a reader what the test is doing in terms of the systems feature set
    - Classicaly described test
    - Requirement is expressed using the developers own words and understanding of the requirements
    - Descriptive method names are often used
    - often meaning of code is expressed using code constructs
    - often refactoring of codebase will cloud the meaning
    - refactoring of codebase can cloud the meaning (e.g. a method name may be renamed to match the code inside it more closely, loosing the original expression of the requirement)

    Development processes

    - Spike & stabilise - where code is developed and tests written after the fact
    - TDD - a development process where tests are written before writing code0
    - BDD - a development process where *behavioural* tests are written before writing code, ideally with input from PO/QA
    - ATDD (acceptance test driven development) - a bit like BDD, where agreed acceptance criteria, typically written using Gherkin (Given, When, Then) are used to drive the implementation

    - Gherkin - a syntax for writing human readable tests (Given, When, Then).

    Properties of tests
    @@ -47,7 +47,6 @@ Properties of tests
    - often related to the particular way that the code has been implemented
    - can be deleted if it the implementation is refactored or changed so it is no longer relevant
    - Poorly describerd test - in which it isn't clear what the test is doing or why
    -

    Verification approaches

  4. mcintyre321 revised this gist Aug 7, 2018. No changes.
  5. mcintyre321 revised this gist Aug 7, 2018. 1 changed file with 11 additions and 9 deletions.
    20 changes: 11 additions & 9 deletions gistfile1.md
    View file
    Original file line number Diff line number Diff line change
    @@ -1,16 +1,17 @@
    Test scopes

    - Unit test - an isolated test around a single unit via it's public interface (often a class, or a series of related classes)
    - Unit test - an isolated test around a single 'unit' of code, although that can be anything from a method to a class to a series of (related) classes.
    - Component test - same as a unit test
    - Isolated test - a test that doesn't do any I/O, i.e. the Ports have been filled with in-memory Adapters
    - Integration test - a test that interacts with deployed instances of the code and related services, possiby with some mocked items
    - End to End test - a test that entirely interacts with deployed instances
    - Integration test - a test that interacts with deployed instances of the code and related services, possiby with some Test Doubles (mocked/faked/stubbed etc).
    - End to End test - a test that entirely interacts with deployed instances using public interfaces
    - Test-per-class - a convention that there should be one unit test for each class

    Uses of tests

    - Development test - a test that was created to aid the process of development (not necessarily TDD)
    - Acceptance test - a test that needs to pass in order to determine a new feature is complete
    - Regression test - a test that ensures existing features are working
    - Acceptance test - a test that demonstrates an acceptance criteria is fulfilled.
    - Regression test - a test that ensures existing features are working. Actually all acceptance tests
    - Smoke test - run after releasem, verifies a major feature is working, typically an end to end test

    Descriptive styles
    @@ -25,13 +26,12 @@ Descriptive styles
    - often meaning of code is expressed using code constructs
    - often refactoring of codebase will cloud the meaning


    Development processes

    - Spike & stabilise - where code is developed and tests written after the fact
    - TDD - a development process where tests are written before writing code0
    - BDD - a development process where *behavioural* tests are written before writing code, ideally with input from PO/QA
    - ATDD (acceptance test driven development) - a bit like BDD
    - ATDD (acceptance test driven development) - a bit like BDD, where agreed acceptance criteria, typically written using Gherkin (Given, When, Then) are used to drive the implementation

    - Gherkin - a syntax for writing human readable tests (Given, When, Then).

    @@ -43,9 +43,11 @@ Properties of tests
    - tests that are bound to a particular implementation of a feature
    - often break or become obsolete when a feature is refactored
    - Expendable test (AKA throwaway)
    - a test which is not part of the acceptance/regression pack, typically a development test
    - can be deleted if it becomes hard to maintain or slow
    - a test which is not tied to an acceptance criteria
    - often related to the particular way that the code has been implemented
    - can be deleted if it the implementation is refactored or changed so it is no longer relevant
    - Poorly describerd test - in which it isn't clear what the test is doing or why
    -

    Verification approaches

  6. mcintyre321 revised this gist Feb 1, 2018. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion gistfile1.md
    View file
    Original file line number Diff line number Diff line change
    @@ -1,7 +1,7 @@
    Test scopes

    - Unit test - an isolated test around a single unit via it's public interface (often a class, or a series of related classes)
    - Component test - a test that verifies multiple units of source code are working
    - Component test - same as a unit test
    - Isolated test - a test that doesn't do any I/O, i.e. the Ports have been filled with in-memory Adapters
    - Integration test - a test that interacts with deployed instances of the code and related services, possiby with some mocked items
    - End to End test - a test that entirely interacts with deployed instances
  7. mcintyre321 revised this gist Feb 1, 2018. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion gistfile1.md
    View file
    Original file line number Diff line number Diff line change
    @@ -1,6 +1,6 @@
    Test scopes

    - Unit test - an isolated test around a single unit (usually a class)
    - Unit test - an isolated test around a single unit via it's public interface (often a class, or a series of related classes)
    - Component test - a test that verifies multiple units of source code are working
    - Isolated test - a test that doesn't do any I/O, i.e. the Ports have been filled with in-memory Adapters
    - Integration test - a test that interacts with deployed instances of the code and related services, possiby with some mocked items
  8. mcintyre321 revised this gist Feb 1, 2018. 1 changed file with 2 additions and 1 deletion.
    3 changes: 2 additions & 1 deletion gistfile1.md
    View file
    Original file line number Diff line number Diff line change
    @@ -31,8 +31,9 @@ Development processes
    - Spike & stabilise - where code is developed and tests written after the fact
    - TDD - a development process where tests are written before writing code0
    - BDD - a development process where *behavioural* tests are written before writing code, ideally with input from PO/QA
    - ATDD (acceptance test driven development) - a bit like BDD

    - Gherkin - a syntax for writing human readable tests (Given, When, Then)
    - Gherkin - a syntax for writing human readable tests (Given, When, Then).

    Properties of tests

  9. mcintyre321 revised this gist Feb 1, 2018. 1 changed file with 3 additions and 2 deletions.
    5 changes: 3 additions & 2 deletions gistfile1.md
    View file
    Original file line number Diff line number Diff line change
    @@ -1,8 +1,9 @@
    Test scopes

    - Unit test - a test that verifies single units of source code are working
    - Unit test - an isolated test around a single unit (usually a class)
    - Component test - a test that verifies multiple units of source code are working
    - Integration test - a test that interacts with deployed instances of the code and related services
    - Isolated test - a test that doesn't do any I/O, i.e. the Ports have been filled with in-memory Adapters
    - Integration test - a test that interacts with deployed instances of the code and related services, possiby with some mocked items
    - End to End test - a test that entirely interacts with deployed instances

    Uses of tests
  10. mcintyre321 revised this gist Apr 28, 2015. 1 changed file with 1 addition and 0 deletions.
    1 change: 1 addition & 0 deletions gistfile1.md
    View file
    Original file line number Diff line number Diff line change
    @@ -60,4 +60,5 @@ Test code constructs
    - Stub. A custom implementation which returns canned responses
    - Mock. An object with programmable responses and can have its responses recorded
    - Fake. lightweight implementation of the component. e.g. a repo that uses a hashtable under the hood
    - Cake - something you deserve for reading this far.

  11. mcintyre321 revised this gist Apr 28, 2015. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion gistfile1.md
    View file
    Original file line number Diff line number Diff line change
    @@ -28,7 +28,7 @@ Descriptive styles
    Development processes

    - Spike & stabilise - where code is developed and tests written after the fact
    - TDD - a development process where tests are written before writing code
    - TDD - a development process where tests are written before writing code0
    - BDD - a development process where *behavioural* tests are written before writing code, ideally with input from PO/QA

    - Gherkin - a syntax for writing human readable tests (Given, When, Then)
  12. mcintyre321 revised this gist Apr 28, 2015. 1 changed file with 3 additions and 3 deletions.
    6 changes: 3 additions & 3 deletions gistfile1.md
    View file
    Original file line number Diff line number Diff line change
    @@ -57,7 +57,7 @@ Verification approaches
    Test code constructs

    - Test double - a component used in a unit test which acts in stead of a real component e.g.
    - a Stub. A custom implementation which returns canned responses
    - a Mock. An object with programmable responses and can have its responses recorded
    - a lightweight implementation of the component. e.g. a repo that uses a hashtable under the hood
    - Stub. A custom implementation which returns canned responses
    - Mock. An object with programmable responses and can have its responses recorded
    - Fake. lightweight implementation of the component. e.g. a repo that uses a hashtable under the hood

  13. mcintyre321 revised this gist Apr 28, 2015. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion gistfile1.md
    View file
    Original file line number Diff line number Diff line change
    @@ -20,7 +20,7 @@ Descriptive styles
    - typically human (product owner/qa) readable
    - should not become obsolete when an implementation is altered (although may require refactoring)
    - Non-behavioural test
    - a test where is it not clear to a reader what the test is doing
    - a test where is it not clear to a reader what the test is doing in terms of the systems feature set
    - often meaning of code is expressed using code constructs
    - often refactoring of codebase will cloud the meaning

  14. mcintyre321 revised this gist Apr 28, 2015. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion gistfile1.md
    View file
    Original file line number Diff line number Diff line change
    @@ -40,7 +40,7 @@ Properties of tests
    - Coupled tests
    - tests that are bound to a particular implementation of a feature
    - often break or become obsolete when a feature is refactored
    - Expendable test
    - Expendable test (AKA throwaway)
    - a test which is not part of the acceptance/regression pack, typically a development test
    - can be deleted if it becomes hard to maintain or slow
    - Poorly describerd test - in which it isn't clear what the test is doing or why
  15. mcintyre321 revised this gist Apr 28, 2015. 1 changed file with 3 additions and 1 deletion.
    4 changes: 3 additions & 1 deletion gistfile1.md
    View file
    Original file line number Diff line number Diff line change
    @@ -19,11 +19,12 @@ Descriptive styles
    - not to be confused with Mockist tests
    - typically human (product owner/qa) readable
    - should not become obsolete when an implementation is altered (although may require refactoring)
    - Poorly described test
    - Non-behavioural test
    - a test where is it not clear to a reader what the test is doing
    - often meaning of code is expressed using code constructs
    - often refactoring of codebase will cloud the meaning


    Development processes

    - Spike & stabilise - where code is developed and tests written after the fact
    @@ -42,6 +43,7 @@ Properties of tests
    - Expendable test
    - a test which is not part of the acceptance/regression pack, typically a development test
    - can be deleted if it becomes hard to maintain or slow
    - Poorly describerd test - in which it isn't clear what the test is doing or why

    Verification approaches

  16. mcintyre321 revised this gist Apr 28, 2015. 1 changed file with 21 additions and 9 deletions.
    30 changes: 21 additions & 9 deletions gistfile1.md
    View file
    Original file line number Diff line number Diff line change
    @@ -1,13 +1,18 @@
    Test scopes

    - Unit test - a test that verifies single units of source code are working
    - Component test - a test that verifies multiple units of source code are working
    - Integration test - a test that interacts with deployed instances of the code and related services
    - End to End test - a test that entirely interacts with deployed instances
    - Development test - a test that was created during the process of development (not necessarily TDD)

    Uses of tests

    - Development test - a test that was created to aid the process of development (not necessarily TDD)
    - Acceptance test - a test that needs to pass in order to determine a new feature is complete
    - Regression test - a test that ensures existing features are working
    - Smoke test - run after releasem, verifies a major feature is working, typically an end to end test


    Descriptive styles

    - Behavioural test (BDD terminology)
    - a test that is described in terms of a terms of desired behavior of the unit
    @@ -19,18 +24,26 @@
    - often meaning of code is expressed using code constructs
    - often refactoring of codebase will cloud the meaning

    - TDD - a development process where unit tests are written before writing code
    - BDD - a development process where behavioural tests are written before writing code
    Development processes

    - Spike & stabilise - where code is developed and tests written after the fact
    - TDD - a development process where tests are written before writing code
    - BDD - a development process where *behavioural* tests are written before writing code, ideally with input from PO/QA

    - Gherkin - a syntax for writing human readable tests (Given, When, Then)

    Properties of tests

    - Fast tests - tests that don't use disk/network calls, or do so sparingly
    - Slow tests - tests that talk to disk/network/browser and so run slowly
    - Coupled tests
    - tests that are bound to a particular implementation of a feature
    - often break or become obsolete when a feature is refactored
    - Expendable test
    - a test which is not part of the acceptance/regression pack, typically a development test
    - can be deleted if it becomes hard to maintain or slow

    - Fast tests - tests that don't use disk/network calls, or do so sparingly
    - Slow tests - tests that talk to disk/network/browser and so run slowly
    Verification approaches

    - Interaction based test (AKA Mockist test)
    - in which a test functions by verifying execution of methods of the components involved
    @@ -39,11 +52,10 @@
    - State based test (AKA Stateist, classicist)
    - in which a test functions by verifying values that are set as the result of a test

    Test code constructs

    - Test double - a component used in a unit test which acts in stead of a real component e.g.
    - a Stub. A custom implementation which returns canned responses
    - a Mock. An object with programmable responses and can have its responses recorded
    - a lightweight implementation of the component. e.g. a repo that uses a hashtable under the hood

    Expendable test
    - a test which is not part of the acceptance/regression pack
    - can be deleted if it becomes hard to maintain or slow
  17. mcintyre321 revised this gist Apr 28, 2015. 1 changed file with 1 addition and 0 deletions.
    1 change: 1 addition & 0 deletions gistfile1.md
    View file
    Original file line number Diff line number Diff line change
    @@ -22,6 +22,7 @@
    - TDD - a development process where unit tests are written before writing code
    - BDD - a development process where behavioural tests are written before writing code


    - Gherkin - a syntax for writing human readable tests (Given, When, Then)

    - Coupled tests
  18. mcintyre321 revised this gist Apr 28, 2015. 1 changed file with 4 additions and 4 deletions.
    8 changes: 4 additions & 4 deletions gistfile1.md
    View file
    Original file line number Diff line number Diff line change
    @@ -19,12 +19,12 @@
    - often meaning of code is expressed using code constructs
    - often refactoring of codebase will cloud the meaning

    - TDD - a development process where unit tests are written before writing code
    - BDD - a development process where behavioural tests are written before writing code
    - TDD - a development process where unit tests are written before writing code
    - BDD - a development process where behavioural tests are written before writing code

    - Gherkin - a syntax for writing human readable tests (Given, When, Then)
    - Gherkin - a syntax for writing human readable tests (Given, When, Then)

    - Coupled tests
    - Coupled tests
    - tests that are bound to a particular implementation of a feature
    - often break or become obsolete when a feature is refactored

  19. mcintyre321 revised this gist Apr 28, 2015. 1 changed file with 7 additions and 7 deletions.
    14 changes: 7 additions & 7 deletions gistfile1.md
    View file
    Original file line number Diff line number Diff line change
    @@ -10,14 +10,14 @@


    - Behavioural test (BDD terminology)
    - a test that is described in terms of a terms of desired behavior of the unit
    - not to be confused with Mockist tests
    - typically human (product owner/qa) readable
    - should not become obsolete when an implementation is altered (although may require refactoring)
    - a test that is described in terms of a terms of desired behavior of the unit
    - not to be confused with Mockist tests
    - typically human (product owner/qa) readable
    - should not become obsolete when an implementation is altered (although may require refactoring)
    - Poorly described test
    - a test where is it not clear to a reader what the test is doing
    - often meaning of code is expressed using code constructs
    - often refactoring of codebase will cloud the meaning
    - a test where is it not clear to a reader what the test is doing
    - often meaning of code is expressed using code constructs
    - often refactoring of codebase will cloud the meaning

    - TDD - a development process where unit tests are written before writing code
    - BDD - a development process where behavioural tests are written before writing code
  20. mcintyre321 revised this gist Apr 28, 2015. No changes.
  21. mcintyre321 revised this gist Apr 28, 2015. 1 changed file with 0 additions and 2 deletions.
    2 changes: 0 additions & 2 deletions gistfile1.md
    View file
    Original file line number Diff line number Diff line change
    @@ -19,8 +19,6 @@
    - often meaning of code is expressed using code constructs
    - often refactoring of codebase will cloud the meaning



    - TDD - a development process where unit tests are written before writing code
    - BDD - a development process where behavioural tests are written before writing code

  22. mcintyre321 revised this gist Apr 28, 2015. 1 changed file with 0 additions and 1 deletion.
    1 change: 0 additions & 1 deletion gistfile1.md
    View file
    Original file line number Diff line number Diff line change
    @@ -2,7 +2,6 @@
    - Component test - a test that verifies multiple units of source code are working
    - Integration test - a test that interacts with deployed instances of the code and related services
    - End to End test - a test that entirely interacts with deployed instances

    - Development test - a test that was created during the process of development (not necessarily TDD)
    - Acceptance test - a test that needs to pass in order to determine a new feature is complete
    - Regression test - a test that ensures existing features are working
  23. mcintyre321 revised this gist Apr 28, 2015. 1 changed file with 24 additions and 24 deletions.
    48 changes: 24 additions & 24 deletions gistfile1.md
    View file
    Original file line number Diff line number Diff line change
    @@ -1,4 +1,3 @@

    - Unit test - a test that verifies single units of source code are working
    - Component test - a test that verifies multiple units of source code are working
    - Integration test - a test that interacts with deployed instances of the code and related services
    @@ -11,40 +10,41 @@



    - Poorly described test - meaning of code is expressed using code constructs
    - refactoring of codebase will cloud the meaning
    - Behavioural test (BDD terminology)
    - a test that is described in terms of a terms of desired behavior of the unit
    - not to be confused with Mockist tests
    - typically human (product owner/qa) readable
    - should not become obsolete when an implementation is altered (although may require refactoring)
    - Poorly described test
    - a test where is it not clear to a reader what the test is doing
    - often meaning of code is expressed using code constructs
    - often refactoring of codebase will cloud the meaning



    TDD - a development process where unit tests are written before writing code
    BDD - a development process where behavioural tests are written before writing code
    - TDD - a development process where unit tests are written before writing code
    - BDD - a development process where behavioural tests are written before writing code

    Gherkin - a syntax for writing human readable tests (Given, When, Then)
    - Gherkin - a syntax for writing human readable tests (Given, When, Then)

    Coupled tests
    - Coupled tests
    - tests that are bound to a particular implementation of a feature
    - break or become obsolete when a feature is refactored


    Fast tests - tests that don't use disk/network calls, or do so sparingly
    Slow tests - tests that talk to disk/network/browser and so run slowly

    Interaction based test (AKA Mockist test)
    - in which a test functions by verifying execution of methods of the components involved
    - some places call them behavioural tests, but shouldn't
    - often tightly coupled to implementation
    State based test (AKA Stateist, classicist)
    - in which a test functions by verifying values that are set as the result of a test

    Test double - a component used in a unit test which acts in stead of a real component e.g.
    - a Stub. A custom implementation which returns canned responses
    - a Mock. An object with programmable responses and can have its responses recorded
    - a lightweight implementation of the component. e.g. a repo that uses a hashtable under the hood
    - often break or become obsolete when a feature is refactored

    - Fast tests - tests that don't use disk/network calls, or do so sparingly
    - Slow tests - tests that talk to disk/network/browser and so run slowly

    - Interaction based test (AKA Mockist test)
    - in which a test functions by verifying execution of methods of the components involved
    - some places call them behavioural tests, but shouldn't
    - often tightly coupled to implementation
    - State based test (AKA Stateist, classicist)
    - in which a test functions by verifying values that are set as the result of a test

    - Test double - a component used in a unit test which acts in stead of a real component e.g.
    - a Stub. A custom implementation which returns canned responses
    - a Mock. An object with programmable responses and can have its responses recorded
    - a lightweight implementation of the component. e.g. a repo that uses a hashtable under the hood

    Expendable test
    - a test which is not part of the acceptance/regression pack
  24. mcintyre321 revised this gist Apr 28, 2015. 1 changed file with 8 additions and 19 deletions.
    27 changes: 8 additions & 19 deletions gistfile1.md
    View file
    Original file line number Diff line number Diff line change
    @@ -1,30 +1,19 @@

    - Unit test - a test that verifies single units of source code are working
    - Component test - a test that verifies multiple units of source code are working
    - Integration test - a test that interacts with deployed instances of the code and related services
    - End to End test - a test that entirely interacts with deployed instances

    Development test
    - a test that was created during the process of development (not necessarily TDD)

    Acceptance test
    - a test that needs to pass in order to determine a new feature is complete

    Regression test
    - a test that ensures existing features are working.
    - usually built from acceptance tests

    Smoke test
    - verifies a major feature is working, run after release
    - often a subset of the regresion pack
    - typically end to end tests

    - Development test - a test that was created during the process of development (not necessarily TDD)
    - Acceptance test - a test that needs to pass in order to determine a new feature is complete
    - Regression test - a test that ensures existing features are working
    - Smoke test - run after releasem, verifies a major feature is working, typically an end to end test


    Poorly described test
    - meaning of code is expressed using code constructs
    - refactoring of codebase will cloud the meaning

    Behavioural test (BDD terminology)
    - Poorly described test - meaning of code is expressed using code constructs
    - refactoring of codebase will cloud the meaning
    - Behavioural test (BDD terminology)
    - a test that is described in terms of a terms of desired behavior of the unit
    - not to be confused with Mockist tests
    - typically human (product owner/qa) readable
  25. mcintyre321 revised this gist Apr 28, 2015. 1 changed file with 10 additions and 6 deletions.
    16 changes: 10 additions & 6 deletions gistfile1.md
    View file
    Original file line number Diff line number Diff line change
    @@ -1,15 +1,18 @@
    - Unit test - a test that verifies single units of source code are working
    - Component test - a test that verifies multiple units of source code are working
    - Integration test - a test that interacts with deployed instances of the code and related services
    - End to End test - a test that entirely interacts with deployed instances

    Unit test - a test that verifies single units of source code are working
    Component test - a test that verifies multiple units of source code are working
    Integration test - a test that interacts with deployed instances of the code and related services
    End to End test - a test that entirely interacts with deployed instances

    Development test
    - a test that was created during the process of development (not necessarily TDD)

    Acceptance test
    - a test that needs to pass in order to determine a new feature is complete

    Regression test
    - a test that ensures existing features are working.
    - usually built from acceptance tests

    Smoke test
    - verifies a major feature is working, run after release
    - often a subset of the regresion pack
    @@ -20,13 +23,14 @@ Smoke test
    Poorly described test
    - meaning of code is expressed using code constructs
    - refactoring of codebase will cloud the meaning

    Behavioural test (BDD terminology)
    - a test that is described in terms of a terms of desired behavior of the unit
    - not to be confused with Mockist tests
    - typically human (product owner/qa) readable
    - should not become obsolete when an implementation is altered (although may require refactoring)

    End to End test - a test that executes entirely against deployed instances


    TDD - a development process where unit tests are written before writing code
    BDD - a development process where behavioural tests are written before writing code
  26. mcintyre321 revised this gist Apr 28, 2015. 1 changed file with 1 addition and 2 deletions.
    3 changes: 1 addition & 2 deletions gistfile1.md
    View file
    Original file line number Diff line number Diff line change
    @@ -1,5 +1,4 @@


    Unit test - a test that verifies single units of source code are working
    Component test - a test that verifies multiple units of source code are working
    Integration test - a test that interacts with deployed instances of the code and related services
    @@ -17,10 +16,10 @@ Smoke test
    - typically end to end tests



    Poorly described test
    - meaning of code is expressed using code constructs
    - refactoring of codebase will cloud the meaning

    Behavioural test (BDD terminology)
    - a test that is described in terms of a terms of desired behavior of the unit
    - not to be confused with Mockist tests
  27. mcintyre321 created this gist Apr 28, 2015.
    59 changes: 59 additions & 0 deletions gistfile1.md
    View file
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,59 @@


    Unit test - a test that verifies single units of source code are working
    Component test - a test that verifies multiple units of source code are working
    Integration test - a test that interacts with deployed instances of the code and related services
    End to End test - a test that entirely interacts with deployed instances


    Acceptance test
    - a test that needs to pass in order to determine a new feature is complete
    Regression test
    - a test that ensures existing features are working.
    - usually built from acceptance tests
    Smoke test
    - verifies a major feature is working, run after release
    - often a subset of the regresion pack
    - typically end to end tests


    Poorly described test
    - meaning of code is expressed using code constructs
    - refactoring of codebase will cloud the meaning

    Behavioural test (BDD terminology)
    - a test that is described in terms of a terms of desired behavior of the unit
    - not to be confused with Mockist tests
    - typically human (product owner/qa) readable
    - should not become obsolete when an implementation is altered (although may require refactoring)

    End to End test - a test that executes entirely against deployed instances

    TDD - a development process where unit tests are written before writing code
    BDD - a development process where behavioural tests are written before writing code

    Gherkin - a syntax for writing human readable tests (Given, When, Then)

    Coupled tests
    - tests that are bound to a particular implementation of a feature
    - break or become obsolete when a feature is refactored


    Fast tests - tests that don't use disk/network calls, or do so sparingly
    Slow tests - tests that talk to disk/network/browser and so run slowly

    Interaction based test (AKA Mockist test)
    - in which a test functions by verifying execution of methods of the components involved
    - some places call them behavioural tests, but shouldn't
    - often tightly coupled to implementation
    State based test (AKA Stateist, classicist)
    - in which a test functions by verifying values that are set as the result of a test

    Test double - a component used in a unit test which acts in stead of a real component e.g.
    - a Stub. A custom implementation which returns canned responses
    - a Mock. An object with programmable responses and can have its responses recorded
    - a lightweight implementation of the component. e.g. a repo that uses a hashtable under the hood

    Expendable test
    - a test which is not part of the acceptance/regression pack
    - can be deleted if it becomes hard to maintain or slow