3.8 KiB

Raw Permalink Blame History

Two Fer

Welcome to Two Fer on Exercism's Java Track. If you need help running the tests or submitting your code, check out HELP.md.

Introduction

In some English accents, when you say "two for" quickly, it sounds like "two fer". Two-for-one is a way of saying that if you buy one, you also get one for free. So the phrase "two-fer" often implies a two-for-one offer.

Imagine a bakery that has a holiday offer where you can buy two cookies for the price of one ("two-fer one!"). You go for the offer and (very generously) decide to give the extra cookie to a friend.

Instructions

Your task is to determine what you will say as you give away the extra cookie.

If your friend likes cookies, and is named Do-yun, then you will say:

One for Do-yun, one for me.

If your friend doesn't like cookies, you give the cookie to the next person in line at the bakery. Since you don't know their name, you will say you instead.

One for you, one for me.

Here are some examples:

Name	Dialogue
Alice	One for Alice, one for me.
Bohdan	One for Bohdan, one for me.
	One for you, one for me.
Zaphod	One for Zaphod, one for me.

Before you start, make sure you understand how to write code that can pass the test cases. For more context, check out this tutorial.

Most Java exercises include multiple test cases. These cases are structured to support a useful process known as test-driven development (TDD). TDD involves repeating a structured cycle that helps programmers build complex functionality piece by piece rather than all at once. That cycle can be described as follows:

Add a test that describes one piece of desired functionality your code is currently missing.
Run the tests to verify that this newly-added test fails.
Update your existing code until:
- All the old tests continue to pass;
- The new test also passes.
Clean up your code, making sure that all tests continue to pass. This typically involves renaming variables, removing duplicated chunks of logic, removing leftover logging, etc.
Return to step 1 until all desired functionality has been built!

The test files in this track contain all the tests your solution should pass to be considered valid. That doesn't immediately seem to be compatible with the cycle described above, in which tests are written one by one. However, the tool that we use to write our tests, JUnit, provides an @Ignore annotation that can be used to temporarily skip an already-written test. Using this annotation, we make sure that the test files we deliver to you satisfy the following rules:

The first test in any test file is not skipped by default.
All but the first test in any test file are skipped by default.

This allows you to simulate the TDD cycle by following these slightly-modified steps:

Run the tests to verify that at most one test currently fails.
Update your existing code until all the non-skipped tests pass.
Clean up your code, making sure that all non-skipped tests continue to pass.
Remove the topmost @Ignore annotation in the test file.
Return to step 1 until no tests are skipped and all tests pass!

Source

Created by

@Smarticles101

Contributed to by

@FridaTveit
@ikhadykin
@jmrunkle
@jssander
@kytrinyx
@lemoncurry
@msomji
@muzimuzhi
@rdavid1099
@sjwarner-bp
@SleeplessByte
@sshine
@stkent
@uzilan
@Valkryst
@ymoskovits

Based on

https://github.com/exercism/problem-specifications/issues/757

3.8 KiB Raw Permalink Blame History