2. Paul Peng Deng
I am an experienced and enthusiastic full stack IoT (Internet of
Things) application developer.
Have hands-on experience in wide range of wireless
communication protocols and big data cloud applications. With
innovation in my genes, I translate my idea into design and
working prototype rapidly to evaluate potential new products or
services.
I currently work for Intercel Australia in Melbourne and open for all
opportunities.
Author
3. Revision History
Revision Date Comments
0.1 20 January 2015 Draft
0.2 21 January 2015 Test, UML, How to Run, Future Work
0.3 22 January 2015 Typos, text format, rephrase sentences
Licence
Creative Commons
Attribution 4.0 International (CC BY 4.0)
You are free to:
Share — copy and redistribute the material in any medium or format
Adapt — remix, transform, and build upon the material
for any purpose, even commercially.
The licensor cannot revoke these freedoms as long as you follow the license terms.
Under the following terms:
Attribution — You must give appropriate credit, provide a link to the license, and
indicate if changes were made. You may do so in any reasonable manner, but not in
any way that suggests the licensor endorses you or your use.
No additional restrictions — You may not apply legal terms or technological measures that
legally restrict others from doing anything the license permits.
4. http://dengpeng.de
1
TOY ROBOT SIMULATOR
Table of Contents
Requirements............................................................................................................................... 2
Description ............................................................................................................................... 2
Constraints............................................................................................................................... 2
Example Input and Output....................................................................................................... 3
Deliverables.............................................................................................................................. 3
Paul Deng’s Java Implementation .............................................................................................. 4
Deliverables.............................................................................................................................. 4
How to Run............................................................................................................................... 4
UML .......................................................................................................................................... 4
Test........................................................................................................................................... 5
Summary.............................................................................................................................. 5
Junit Test Cases .................................................................................................................. 5
Future Work............................................................................................................................ 10
Requirements Verification................................................................................................. 10
Code Quality Improvements.............................................................................................. 10
Use Design Pattern............................................................................................................ 10
Add Interactive Mode ........................................................................................................ 10
Better Test Coverage......................................................................................................... 11
Better In-Line Comments................................................................................................... 11
Better Version Control ....................................................................................................... 11
Better Documentation ....................................................................................................... 11
Add UI................................................................................................................................. 11
Similar Projects and Implementations ..................................................................................... 11
Notes .......................................................................................................................................... 12
5. http://dengpeng.de
2
TOY ROBOT SIMULATOR
Requirements
Description
The application is a simulation of a toy robot moving on a square tabletop, of
dimensions 5 units x 5 units.
There are no other obstructions on the table surface.
The robot is free to roam around the surface of the table, but must be prevented from
falling to destruction. Any movement that would result in the robot falling from the table
must be prevented, however further valid movement commands must still be allowed.
Create an application that can read in commands of the following form -
PLACE X,Y,F
MOVE
LEFT
RIGHT
REPORT
PLACE will put the toy robot on the table in position X,Y and facing NORTH, SOUTH,
EAST or WEST.
The origin (0,0) can be considered to be the SOUTH WEST most corner.
The first valid command to the robot is a PLACE command, after that, any sequence of
commands may be issued, in any order, including another PLACE command. The
application should discard all commands in the sequence until a valid PLACE command
has been executed.
MOVE will move the toy robot one unit forward in the direction it is currently facing.
LEFT and RIGHT will rotate the robot 90 degrees in the specified direction without
changing the position of the robot.
REPORT will announce the X,Y and F of the robot. This can be in any form, but standard
output is sufficient.
A robot that is not on the table can choose then ignore the MOVE, LEFT, RIGHT and
REPORT commands.
Input can be from a file, or from standard input, as the developer chooses.
Provide test data to exercise the application.
Constraints
The toy robot must not fall off the table during movement. This also includes the initial
placement of the toy robot.
Any move that would cause the robot to fall must be ignored.
6. http://dengpeng.de
3
TOY ROBOT SIMULATOR
Example Input and Output
a)
PLACE 0,0,NORTH
MOVE
REPORT
Output: 0,1,NORTH
b)
PLACE 0,0,NORTH
LEFT
REPORT
Output: 0,0,WEST
c)
PLACE 1,2,EAST
MOVE
MOVE
LEFT
MOVE
REPORT
Output: 3,3,NORTH
Deliverables
The Ruby source files, the test data and any test code.
It is not required to provide any graphical output showing the movement of the toy robot.
7. http://dengpeng.de
4
TOY ROBOT SIMULATOR
Paul Deng’s Java Implementation
Java implementation
File input only. Does not accept input interactively from keyboard
Command line application, no GUI
Deliverables
Deliverables can be downloaded from: http://dengpeng.de/wp-
content/uploads/2015/01/ToyRobotSimulator.zip
Executable JAR: ToyRobotSimulator/dist/ToyRobotSimulator.jar
Java Source File: ToyRobotSimulator/src
Project Document (this document): ToyRobotSimulator/docs/Toy Robot
Simulator.pdf
Junit Source Files: ToyRobotSimulator/src/toyrobotsimulator_testcases
Junit Test Case Input Files: ToyRobotSimulator/testFiles
How to Run
UML
Class Diagram
8. http://dengpeng.de
5
TOY ROBOT SIMULATOR
Test
Summary
This table below extracts requirements from project description and concludes with test
cases and test results. For detail of each individual test case, please read the next section.
# Requirements Test Cases # Results
1 Any movement that would result in the robot falling from
the table must be prevented, however further valid
movement commands must still be allowed.
16, 17, 18, 19 Pass
2 The first valid command to the robot is a PLACE
command.
05, 06 Pass
3 Any sequence of commands may be issued, in any order,
including another PLACE command.
07 Pass
4 The application should discard all commands in the
sequence until a valid PLACE command has been
executed.
07 Pass
5 MOVE will move the toy robot one unit forward in the
direction it is currently facing.
13, 14, 15,
16, 17, 18, 19
Pass
6 LEFT and RIGHT will rotate the robot 90 degrees in the
specified direction without changing the position of the
robot.
13, 14, 15,
16, 17, 18, 19
Pass
7 REPORT will announce the X,Y and F of the robot. 13, 14, 15,
16, 17, 18, 19
Pass
8 A robot that is not on the table can choose then ignore the
MOVE, LEFT, RIGHT and REPORT commands.
05, 08 Pass
9 The toy robot must not fall off the table during movement 16, 17, 18, 19 Pass
10 This also includes the initial placement of the toy robot. 08 Pass
11 Any move that would cause the robot to fall must be
ignored.
16, 17, 18, 19 Pass
12 Example input and output a, b, c 13, 14, 15 Pass
Junit Test Cases
1. Missing argument
Input: java –jar ToyrobotSimulator
Expected output: Only accept 1 argument, 0 given.
2. Too many arguments
Input: java –jar ToyrobotSimulator too many arguments
Expected output: Only accept 1 argument, 3 given.
3. Invalid input file
Input: java –jar ToyrobotSimulator ../testFiles/file_not_exist.txt
Expected output: File not found: ../testFiles/file_not_exist.txt
9. http://dengpeng.de
6
TOY ROBOT SIMULATOR
4. Empty input file
Input: java –jar
ToyrobotSimulator ../testFiles/TestCase_04_EmptyInputFile.txt
Expected output: Empty file: ../testFiles/TestCase_04_EmptyInputFile.txt
5. PLACE command missing
Input commands: MOVE
REPORT
Expected output: Invalid command file:
testFiles/TestCase_05_PLACECommandMissing.txt
Notes In this implementation, no PLACE command means this file is invalid
or corrupted.
However, further verification is required with the QA team or
customer, in order to meet the exact specification.
6. Invalid PLACE command
Input commands: PLACE 0,southeast
LEFT
REPORT
Expected output: Invalid command file:
testFiles/TestCase_06_InvalidPLACECommand.txt
Notes In this implementation, invalid PLACE command means this file is
invalid or corrupted.
However, further verification is required with the QA team or
customer, in order to meet the exact specification.
7. Duplicate PLACE commands
Input commands: MOVE
REPORT
PLACE 1,2,EAST
PLACE 0,0,NORTH
MOVE
REPORT
PLACE 0,0,NORTH
LEFT
REPORT
PLACE 1,2,EAST
MOVE
MOVE
LEFT
MOVE
REPORT
Expected output: Output: 0,1,NORTH
Output: 0,0,WEST
Output: 3,3,NORTH
8. PLACE outside of table
Input commands: PLACE 10,10,NORTH
10. http://dengpeng.de
7
TOY ROBOT SIMULATOR
MOVE
REPORT
Expected output: Invalid command file:
testFiles/TestCase_08_PLACEOutsideOfTable.txt
Notes: In this implementation, PLACE outside of table means it is an invalid
PLACE command.
However, further verification is required with the QA team or
customer, in order to meet the exact specification.
9. Invalid MOVE, LEFT and RIGHT command
Input commands: PLACE 1,2,EAST
movebla
leftbla
rightbla
REPORT
Expected output: Output: 1,2,EAST
10. REPORT command missing
Input commands: PLACE 1,2,EAST
MOVE
MOVE
LEFT
MOVE
Expected output:
Notes: In this implementation, missing REPORT is considered valid, thus no
output.
However, further verification is required with the QA team or
customer, in order to meet the exact specification.
11. Invalid REPORT command
Input commands: PLACE 1,2,EAST
MOVE
MOVE
LEFT
MOVE
REPORTbla
Expected output:
Notes: In this implementation, invalid REPORT is ignored, thus no output.
However, further verification is required with the QA team or
customer, in order to meet the exact specification.
12. Unsolicited command
Input commands: PLACE 1,2,EAST
MOVE
MOVE
LEFT
MOVE
This is a unsolicited command line
11. http://dengpeng.de
8
TOY ROBOT SIMULATOR
REPORT
Expected output:
Notes: In this implementation, invalid command is ignored.
However, further verification is required with the QA team or
customer, in order to meet the exact specification.
13. Test case a
This test case is from project description.
Input commands: PLACE 0,0,NORTH
MOVE
REPORT
Expected output: Output: 0,1,NORTH
14. Test case b
This test case is from project description.
Input commands: PLACE 0,0,NORTH
LEFT
REPORT
Expected output: Output: 0,0,WEST
15. Test case c
This test case is from project description.
Input commands: PLACE 1,2,EAST
MOVE
MOVE
LEFT
MOVE
REPORT
Expected output: Output: 3,3,NORTH
16. Move North outbound
Input commands: PLACE 0,0,NORTH
MOVE
MOVE
MOVE
MOVE
MOVE
MOVE
MOVE
MOVE
MOVE
MOVE
MOVE
MOVE
MOVE
MOVE
12. http://dengpeng.de
9
TOY ROBOT SIMULATOR
MOVE
MOVE
MOVE
MOVE
RIGHT
MOVE
REPORT
Expected output: Output: 1,4,EAST
17. Move South outbound
Input commands: PLACE 0,0,SOUTH
MOVE
MOVE
MOVE
MOVE
MOVE
MOVE
MOVE
MOVE
MOVE
MOVE
MOVE
MOVE
MOVE
MOVE
MOVE
LEFT
MOVE
REPORT
Expected output: Output: 1,0,EAST
18. Move West outbound
Input commands: PLACE 0,0,WEST
MOVE
MOVE
MOVE
MOVE
MOVE
MOVE
MOVE
MOVE
MOVE
MOVE
MOVE
MOVE
RIGHT
MOVE
REPORT
Expected output: Output: 0,1,NORTH
13. http://dengpeng.de
10
TOY ROBOT SIMULATOR
19. Move East outbound
Input commands: PLACE 0,0,EAST
MOVE
MOVE
MOVE
MOVE
MOVE
MOVE
MOVE
MOVE
MOVE
MOVE
MOVE
MOVE
MOVE
LEFT
MOVE
REPORT
Expected output: Output: 4,1,NORTH
Future Work
Requirements Verification
The following requirements are not clear and need to go back to Project Manager/Customer
to have further verification.
Test Case 05: PLACE Command Missing
Test Case 06: Invalid PLACE Command
Test Case 08: PLACE Outside of Table
Test Case 10: REPORT Command Missing
Test Case 11: Invalid REPORT Command
Test Case 12: Unsolicited command
Code Quality Improvements
Due to the time restriction, the code quality is not very good. Further optimization is
required.
Use Design Pattern
This is a simple application, I decide not to use any design pattern.
However, with the time goes on, new features will be added and it may need to use a proper
design pattern to increase code reuse and maintainability.
Add Interactive Mode
This application only implements file IO. The next version should accept input in real time
and print out result immediately.
14. http://dengpeng.de
11
TOY ROBOT SIMULATOR
Better Test Coverage
Some complex scenarios are not tested in this version, due to time restriction.
Future version should cover them, for example:
multiple PLACE commands with invalid and valid commands mixed
different OSs and different JVMs
Better In-Line Comments
Ad-hoc in line comments in place.
However, it is not idea and should use proper format which aligns with company code
policy.
Better Version Control
SVN or Git is not used for this simple application.
Better Documentation
Only class diagram is presented in this document. Sequence diagram is required to explain
how this application works internally.
Add UI
Attracts more customers.
Similar Projects and Implementations
Ruby implementation: https://github.com/huwr/toy-robot-simulator
js and html5 implementation: http://lisalu.com.au/toy-robot-simulator-using-
javascript-and-html5/
js implementation: http://jsfiddle.net/lisatinglu/cBm2Z/light/
Java implementation: https://groups.google.com/forum/#!msg/happy-
programming/O0-lg6yn1F0/O8E_8qXGvk4J
Ruby implementation: http://thatalexguy.com/posts/2013-07-15-failure-to-
code.html
Discussion: https://joneaves.wordpress.com/2014/07/21/toy-robot-coding-test/
Java implementation: https://github.com/alexwibowo/Robot