xcfit 0.9.0 → 1.0.0

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/FixtureCode/properties.xml

@@ -1,10 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<properties>
-<Files/>
-<Help>Under The Covers : Fixture Code</Help>
-<RecentChanges>true</RecentChanges>
-<Test/>
-<WhereUsed/>
-<saveId>1238165191090</saveId>
-<ticketId>4545566180239902012</ticketId>
-</properties>

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/GracefulName/content.txt

@@ -1,27 +0,0 @@
-!1 Improving Readability using ''Graceful Names''
-If you are not yet accustomed to it, you can make your test tables much more pleasant to read by using ''graceful name'' notation.
-
-Say you have a fixture class named ''!-payroll.fixtures.PaycheckInspector-!'' you can references in your fixture tables as ''Paycheck inspector''.  Both Fit and Slim will manipulate that name back into ''!-PaycheckInspector-!'' by removing punctuation and using camel case.  They will then hunt through a list of known packages for the fixture.
-
-A similar transformation happens with variable and method names too.
-
-Therefore instead of this:
-
-!|payroll.fixtures.PaycheckInspector|
-|employeeId|employeeName|payAmount()|
-|24|Bob|1500|
-
-You can have this:
-
-!|Paycheck inspector.|
-|employee id|employee name|pay amount?|
-|24|Bob|1500|
-
-You can add to the list of packages by using the ''Import'' fixture as follows.
-
-|Import|
-|payroll.fixtures|
-
-This table should appear ''above'' the tables that use the ''!-PaycheckInspector-!'' fixture.  It's a good idea to put your ''Import'' fixtures in a !-SetUp-! page.
-
-

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/GracefulName/properties.xml

@@ -1,8 +0,0 @@
-<?xml version="1.0"?>
-<properties>
-	<Files/>
-	<RecentChanges>true</RecentChanges>
-	<WhereUsed/>
-	<saveId>1225603612907</saveId>
-	<ticketId>-1576090897176335033</ticketId>
-</properties>

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/RestfulTests/content.txt

@@ -1,68 +0,0 @@
-The XML result for a test comes back in the following form:
-{{{
-<testResults>
-	<rootPath>SuiteAcceptanceTests</rootPath>
-	<result>
-		<relativePageName>SuiteWidgetTests.TestBrokenWikiWordLink</relativePageName>
-                <tags>critical,slow</tags>
-		<counts>
-			<right>24</right>
-			<wrong>0</wrong>
-			<ignores>0</ignores>
-			<exceptions>0</exceptions>
-		</counts>
-		<runTimeInMillis>
-			1022
-		</runTimeInMillis>
-		<content>
-                        <![CDATA[HTML OF TEST PAGE
-                </content>
-                <tables>
-                       <table>
-                               <name>decisionTable_0</name>
-                               <row>
-                                       <col>cell_contents</col>
-                                       ...
-                               </row>
-                               ...
-                       </table>
-                       ...
-                </tables>
-               <instructions>
-                       <instructionResult>
-                               <instruction>[decisionTable_1_0, make, decisionTable_1, SetUp]</instruction>
-                               <slimResult>OK</result>
-                               <expectation>
-                                       <instructionId>decisionTable_1_0</instructionId>
-                                       <status>right</status>
-                                       <col>0</col>
-                                       <row>0</row>
-                                       <type>ConstructionExpectation</type>
-                                       <actual>OK</actual>
-                                       <expected>SetUp</expected>
-                                       <evaluationMessage>pass(SetUp)</evaluationMessage>
-                               </expectation>
-                               ...
-                       </instructionResult>
-                       ...
-               </instructions>
-	</result>
-</testResults>
-}}}
-
-
-The 'tables' and 'instructions' elements are only for Slim tests.
- * The 'tables' element encodes the results of all the test tables.  There is a !style_code(<table>) for each table on the test page.  Each has a set of !style_code(<row>) elements, which each have a set of !style_code(<col>) elements, which old the contents of the tested table.
-  * The contents of the columns are encoded with !style_code[pass(xxx)], !style_code[fail(xxx)] etc. These show what parts of the cell contents would be colored red or green
-  * The name of the table is encoded in the !style_code(<name>) element.  This is the name that slim gives to the table, and is used to prefix instruction tags in the expectations (see below).
- * The instruction data documents the slim execution process.  Each instruction represents a single slim command.  You see the command as it was sent to slim, the result as it returned from slim, and the evaluation of the slim table expectation.  This is pretty detailed information, so here are a few things you should know.
-  * !style_code(instructionId) is the id of a single slim instruction.  It is constructed from the table name (see above), and the instruction number within that table.  So an id of decisionTable_1_3 means that the instruction is for the third instruction in the table named decision table_1.
-   * Scenario tables, when executed, are turned into script tables with the same number.  So !style_code(scenarioTable_22) will become !style_code(scriptTable_22).  The third instruction in scenario table 18 called from the 4th instruction in decision table 8 will be !style_code(decisionTable_8_4_scriptTable_18_3).
-  * !style_code(col,row) are the column and row of the expectation.  If scenario tables are involved it's the col,row of the ultimate scenario.
-  * !style_code(type) is the class name of the expectation.  You can pretty much work out the intent.  Here are a few of the more common ones
-   * !style_code(!-ReturnedValueExpectation-!) - This is the one that does almost all the comparisons that you are used to.  Decision tables and script tables use them a lot.
-   * !style_code(!-VoidReturnExpectation-!) - We use this when we call a function (like 'setX') and expect a void return.
-   * !style_code(!-ConstructionExpectation-!) - used when we create a fixture class.
-  * !style_code(expected) - This is the value that the expectation expects to be returned from slim.  Often this is ignored.  Only some expectations actually use it.  !style_code(!-ReturnedValueExpectation-!) uses it of course.
-  * !style_code(actual) - This is what was actually returned by slim.  You also saw this in the !style_code(slimResult) tag, but we present it here because it may have been massaged by internal processing.
-  * !style_code(evaluationMessage) - This is the result of the expectation.  It is a message littered with !style_code[pass()] and !style_code[fail()] markers that let you see the red/green results in symbolic form.

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/RestfulTests/properties.xml

@@ -1,13 +0,0 @@
-<?xml version="1.0"?>
-<properties>
-	<Edit>true</Edit>
-	<Files>true</Files>
-	<Properties>true</Properties>
-	<RecentChanges>true</RecentChanges>
-	<Refactor>true</Refactor>
-	<Search>true</Search>
-	<Versions>true</Versions>
-	<WhereUsed>true</WhereUsed>
-	<saveId>1238693962013</saveId>
-	<ticketId>-8421131222935524094</ticketId>
-</properties>

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/RunningAcceptanceTests/content.txt

@@ -1,20 +0,0 @@
-Acceptance tests are run by hitting the '''Test''' button (or typing ''ALT-t'').  This button appears on any page that has the '''Test''' attribute set.  See [[Page Attributes][PageProperties]].
-
-Any tables that are on the page are run through the Fit framework (See http://fit.c2.com ).
-
-So, for example, click the '''Test''' button (or type ''ALT-t'') and see what happens to the table below:
-
-|eg.Division|
-|numerator|denominator|quotient?|
-|10|2|5|
-|12.6|3|4.2|
-|-3|3|-1|
-|100|0|0|
-|33|3|11|
-
-TroubleshootingAcceptanceTests
-
-!see CustomizingTestExecution
-
-----
-You may also run FitNesseTests by using the CommandLineTestRunner!

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/RunningAcceptanceTests/properties.xml

@@ -1,11 +0,0 @@
-<?xml version="1.0"?>
-<properties>
-	<Files/>
-	<Properties/>
-	<RecentChanges>true</RecentChanges>
-	<Search/>
-	<Test/>
-	<Versions/>
-	<WhereUsed/>
-	<saveId>1052055454364</saveId>
-</properties>

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/RunningFromJunit/content.txt

@@ -1,36 +0,0 @@
-You can run FitNesse Java (Fit and Slim) tests from a developer IDE without starting the FitNesse server. This is a developer-centric approach to running tests and is not suitable for collaboration with customers or testers, but it is very efficient for troubleshooting purposes. FitNesse includes a set of JUnit 4 runner that enables you to execute a test or a suite using JUnit. The runner will execute FitNesse tests in-process by default, allowing you to debug and inspect the fixture or domain code during test execution. Test pass/failure reports are integrated with JUnit but the normal page output (tables etc) gets saved to the disk for later inspection, if required.
-
-The !-FitNese-! runner will report about individual test pages being executed by JUnit. For IDE's this means that the JUnit report window and give you detailed statistics for individual tests in a suite.
-
-!2 Using the !-FitNese-! runner
-To use the !-FitNese-! runner, Define !-fitnesse.junit.FitNesseSuite-! as the runner for a specific test class, using @org.junit.runner.RunWith(). Set the test or suite name to run using the @Name attribute, the root FitNesse path using !-@FitNesseDir-! attribute and the result directory using !-@OutputDir-! attribute.[[Here's a full example.][https://github.com/unclebob/fitnesse/blob/master/test/fitnesse/junit/FitNesseRunnerTest.java]]
-
-!2 What about JUnitHelper?
-JUitHelper is no more. Main reason for this is that FitNesse has become more modular. Now it's possible to execute a set of tests with only a few lines of code. The basics are:
-
- * build a context:
-
-{{{FitNesseContext context = new ContextConfigurator(properties /* a java.util.Properties instance */).makeFitNesseContext();}}}
-
- * get a set of pages you want to execute:
-
-{{{List<WikiPage> pagesToExecute = new SuiteContentsFinder(suiteRoot, null /* optional fitnesse.testrunner.SuiteFilter */, context.root).getAllPagesToRunForThisSuite();}}}
-
- * build a test runner, provide a descriptor with the execution details (e.g. debug mode) for the tests:
-
-{{{final String classPath = new ClassPathBuilder().buildClassPath(pages);
-final PagesByTestSystem pagesByTestSystem = new PagesByTestSystem(pages, context.root, new PagesByTestSystem.DescriptorFactory() {
-    @Override
-    public Descriptor create(WikiPage page) {
-        return new WikiPageDescriptor(page.readOnlyData(), true /* run in-process */, false /* remote debug */, classPath);
-    }
-});
-MultipleTestsRunner testRunner = new MultipleTestsRunner(pagesByTestSystem, context.runningTestingTracker, context.testSystemFactory);}}}
-
- * register a !-TestSystemListener-! on the test runner:
-
-{{{testRunner.addTestSystemListener(new TestSystemListener() { ... });}}}
-
- * execute the tests; test results are reported through the listener:
-
-{{{testRunner.executeTestPages();}}}

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/RunningFromJunit/properties.xml

@@ -1,8 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<properties>
-<Files/>
-<RecentChanges/>
-<Search/>
-<Static/>
-<WhereUsed/>
-</properties>

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/RunningFromMaven/content.txt

@@ -1,7 +0,0 @@
-If you want to run FitNesse tests via Maven there are a couple of options:
-
-1. Use the FitNesse Launcher plugin: http://fitnesse-launcher-maven-plugin.googlecode.com/svn/maven/site/fitnesse-launcher-maven-plugin/config.html
-2. Use the Mafia Maven plugin: https://github.com/sijpesteijn/mafia-maven-plugin
-3. Use the Maven Ant plugin: http://blog.xebia.com/fitnesse-and-dependency-management-with-maven
-
-All performing the same basic tasks (start a server, run tests via a ''test'' or ''integration-test'' target).

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/RunningFromMaven/properties.xml

@@ -1,8 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<properties>
-<Files/>
-<RecentChanges/>
-<Search/>
-<Static/>
-<WhereUsed/>
-</properties>

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/SliM/CommentTable/content.txt

@@ -1,4 +0,0 @@
-|Comment|
-|Comment tables are simply not executed|
-|You|Can|Put|Anything|You|Want|Into|Them|
-|The only requirement|is that the first|cell of the table|must be the word|comment|

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/SliM/CommentTable/properties.xml

@@ -1,16 +0,0 @@
-<?xml version="1.0"?>
-<properties>
-	<Edit/>
-	<Files/>
-	<Help/>
-	<Properties/>
-	<RecentChanges/>
-	<Refactor/>
-	<Search/>
-	<Suites/>
-	<Test/>
-	<Versions/>
-	<WhereUsed/>
-	<saveId>1225490422970</saveId>
-	<ticketId>-5059229174992629731</ticketId>
-</properties>

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/SliM/ConstructorArguments/content.txt

@@ -1,5 +0,0 @@
-Most tables use some kind of fixture class.  That class will be constructed once for each table.  You can pass constructor arguments simply by adding those arguments in table cells after the constructor name.
-
-|Decision:my decision table|constructor argument 1|constructor argument 2|
-|...|
-

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/SliM/ConstructorArguments/properties.xml

@@ -1,13 +0,0 @@
-<?xml version="1.0"?>
-<properties>
-	<Edit>true</Edit>
-	<Files>true</Files>
-	<Properties>true</Properties>
-	<RecentChanges>true</RecentChanges>
-	<Refactor>true</Refactor>
-	<Search>true</Search>
-	<Versions>true</Versions>
-	<WhereUsed>true</WhereUsed>
-	<saveId>1225293418146</saveId>
-	<ticketId>4034578242887246818</ticketId>
-</properties>

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/SliM/CustomTypes/content.txt

@@ -1,23 +0,0 @@
-!2 Adding custom type converters to Slim (Java)
-If you have a fixture whose methods take or return a class that is not one of the standard Slim types, you can add a customer type converter very easily.  There are two different ways to do this.
-
-First, you can use the standard !style_code(!-PropertyEditor-!) mechanism.  You can read about this in the Javadocs for !style_code(!-PropertyEditor-!).  In short, if you have a class named !style_code(!-MyType-!) you can create a class named !style_code(!-MyTypeEditor-!) that implements the !style_code(!-PropertyEditor-!) interface (usually by extending !style_code[!-PropertyEditorSupport-!]).  That's pretty much it.  There are three different search paths for this class, but I'll let you read about that in the Javadocs.
-!note There is an example of this in !-fitnesse.slim.test.ZorkEditor-!
-
-Or, you can use the lower level approach of registering a converter.
-The converter must derive from !-fitnesse.slim.Converter-!.
-{{{
-package fitnesse.slim;
-public interface Converter {
-  public String toString(Object o);
-  Object fromString(String arg);
-} }}} As you can see this is pretty simple.  Your derivative must implement the toString method to convert your type to a string; and it must implement the fromString method to convert the string into your custom type.
-
-Then, in the constructor of first fixture to uses that type simply put the following line of code: {{{fitnesse.slim.converters.ConverterRegistry.addConverter(MyClass.class, new MyClassConverter())}}}
-
-'''Please note''' the application of converters to methods returning !style_code[List]s is special: whether a converter is applied to a method's result depends on its ''declared'' return type:
- * List (exactly, no sub-interface or class implementing it): converter is '''not applied''' (this is needed for some Slim tables, such as !-QueryTable-!).
- * All return types: converter is applied, based on the actual class of the object returned, or on its declared type when !style_code[null] is returned 
-
-
-The technique for other language platforms should be similar to this.  Check the documentation of the Slim port for your platform. 

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/SliM/CustomTypes/properties.xml

@@ -1,13 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<properties>
-<Edit>true</Edit>
-<Files>true</Files>
-<Properties>true</Properties>
-<RecentChanges>true</RecentChanges>
-<Refactor>true</Refactor>
-<Search>true</Search>
-<Versions>true</Versions>
-<WhereUsed>true</WhereUsed>
-<saveId>1232745959476</saveId>
-<ticketId>4415644922513391702</ticketId>
-</properties>

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/SliM/DataTypes/content.txt

@@ -1,11 +0,0 @@
-!1 Data types
- * For numerics, the Java format is used. e.g. Integer.parseInt() or Double,parseDouble() calls.
- * Boolean maps to the strings "true" and "false".
- * Dates convert in and out of a date format of the form dd-MMM-yyyy. (e.g. 10-Oct-1970)
- * Lists of strings are mapped to simple strings of the form ''[a, b, c]''.  Note the brackets and spaces.  This is the standard ''toString'' format for Java Lists.
- * Arrays of Booleans, Integers, Strings, and Doubles map to the form ''[x, y, z]''.
- * !see CustomTypes
-
-!3 Maps.
-The [[Hash Widget][<UserGuide.FitNesseWiki.MarkupLanguageReference.MarkupHashTable]] sends HTML as a string to the Slim Fixture.  Java_Slim and Ruby_Slim will both convert this HTML string into a Map<String,String> (or a hash in the case of Ruby).
-  

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/SliM/DataTypes/properties.xml

@@ -1,13 +0,0 @@
-<?xml version="1.0"?>
-<properties>
-	<Edit>true</Edit>
-	<Files>true</Files>
-	<Properties>true</Properties>
-	<RecentChanges>true</RecentChanges>
-	<Refactor>true</Refactor>
-	<Search>true</Search>
-	<Versions>true</Versions>
-	<WhereUsed>true</WhereUsed>
-	<saveId>1225481584437</saveId>
-	<ticketId>6085177871853100391</ticketId>
-</properties>

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/SliM/DecisionTable/content.txt

@@ -1,116 +0,0 @@
-|should I buy milk                                              |
-|cash in wallet|credit card|pints of milk remaining|go to store?|
-|0             |no         |0                      |no          |
-|10            |no         |0                      |yes         |
-|0             |yes        |0                      |yes         |
-|10            |yes        |0                      |yes         |
-|0             |no         |1                      |no          |
-|10            |no         |1                      |no          |
-|0             |yes        |1                      |no          |
-|10            |yes        |1                      |nope        |
-
-This is a decision table; sometimes known as a truth table. This particular table has three inputs and one output.
-
-Here is the fixture code that it invokes:{{{
-package fitnesse.slim.test;
-
-public class ShouldIBuyMilk {
-  private int dollars;
-  private int pints;
-  private boolean creditCard;
-
-  public void setCashInWallet(int dollars) {
-    this.dollars = dollars;
-  }
-
-  public void setPintsOfMilkRemaining(int pints) {
-    this.pints = pints;
-  }
-
-  public void setCreditCard(String valid) {
-    creditCard = "yes".equals(valid);
-  }
-
-  public String goToStore() {
-    return (pints == 0 && (dollars > 2 || creditCard)) ? "yes" : "no";
-  }
-
-  // The following functions are optional.  If they aren't declared they'll be ignored.
-  public void execute() {
-  }
-
-  public void reset() {
-  }
-
-  public void table(List<List<String>> table) {
-  }
-
-  public void beginTable() {
-  }
-
-  public void endTable() {
-  }
-} }}}
-
-That pretty much explains it all. But let's look at the details a bit more closely.
-
-First of all, there's the name of the table: "should I buy milk". This is named for a decision to be made. That's good style. Decision tables should be named for decisions.Howeverthat name also translates to the fixture class !-ShouldIBuyMilk-!. If you run this test you'll notice that the name turns green. This means that Slim found the fixture class and was able to create an instance of it.
-
-The first cell could also have been ''Decision: should I buy milk,'' ''DT: should I buy milk'', or ''ShouldIBuyMilk'', etc.. The code ''Decision:'' or ''DT:'' tells Slim what kind of table this is.Decisiontable is the default.
-
-Next, there's the row of column headers. If you look carefully at them you'll see that they all correspond to functions in the fixture class. However, the first three correspond to ''set'' functions. That's because they don't have a ''?''. The Decision Table considers them tobe inputs, and automatically calls the appropriately named ''set'' function.
-
-The last column header does have a ''?''. Decision Table considers it to be an output and so calls it as a function and expects a return value. That return value is compared to the contents of the column and turns the corresponding cell red or green depending whether it matches. Note that the cell that contains 'nope' does not match the 'no' that is returned.
-
-The flow is very simple.
-
- 1 First the !style_code(ShouldIBuyMilk) fixture is constructed.
- 1 Next the !style_code(table) method is called if it exists. (see below).
- 1 Next the !style_code(beginTable) method is called, if it exists. Use this for initializations if you want to.
- 1 Then for each row in the table:
-   1 First the !style_code(reset) function is called (if present), just in case you want to prepare or clean up.
-   1 Then all the inputs are loaded by calling the appropriate !style_code(set) functions. Inputs are loaded in the left to right order of their appearance in the header.
-   1 Then the !style_code(execute) function of the fixture is called (if present).
-   1 Finallyall the output functions are called, again in left to right order, and the return values compared to their table cells.
- 1 Finally the !style_code(endTable) method is called, if it exists. Use this for closedown and cleanup if you want to.
-
-!4 Optional Functions
- * !style_code(beginTable) - is called once, just after the !style_code(table) method, and just before the rows are processed. This is for setup and initialization stuff.
- * !style_code(endTable) = is called once, just after the last row has been processed. It's the last function to be called by the table. Use it for cleanup and closedowns.
- * !style_code(reset) - is called once for each row before any !style_code(set) or output functions are called.
- * !style_code(execute) - is called once for each row just after all the !style_code(set) functions have been called, and just before the first output function (if any) are called.
- * !style_code(table) - is called just after the constructor and before the first row is processed. It is passed a list of lists that contain all the cells of the table except for the very first row. The argument contains a list of rows, each row is a list of cells. This is the same format that is passed to the !style_code(doTable) method of the Table table. For the table above the argument would be: !-<br/>-!!style_code([[cash in wallet, credit card, pints of milk remaining, go to store?], [0, no, 0, no], [10, no, 0, yes], [0, yes, 0, yes], [10, yes, 0, yes], [0, no, 1, no], [10, no, 1, no], [0, yes, 1, no], [10, yes, 1, nope]])
-
-There's not much more to it than that.
-
-!4 Well, yes there is.
-But forthatyou should look at SymbolsInTables and ValueComparisons
-
-!4 Exceptions
-When exceptions occur in a decision table, they're displayed inline.
-
-|should I buy milk                                             |
-|cash in wallet|credit card|pints of milk remaining|go tostore?|
-|0             |yes        |1                      |no         |
-|0             |yes        |one                    |no         |
-
-|decision table all done wrong|
-|foo      |bar      |baz?     |
-|-        |         |/        |
-|         |*        |         |
-
-!4 Documentation
-If you want to document thedata givenin a particular row you can just add an extra cell to the right.
-
-|should I buy milk                                                                            |
-|cash in wallet|credit card|pints of milk remaining|go tostore?                               |
-|0             |no         |0                      |no                                        |
-|10            |no         |0                      |yes|plenty of money but no need for a pint|
-
-For more detailed documentation you can add designated comment columns anywhere. Just prefix the header with a hash symbol.
-
-
-|should I buy milk                                                                                              |
-|cash in wallet|# comment                                       |credit card|pints of milk remaining|go tostore?|
-|-2            |we actually allow negative amounts, meaning debt|no         |0                      |no         |
-|1             |must have at least 2 euros                      |no         |0                      |no         |