Description

5/5 - (2 votes)

1 Required software

You need an IDE for C# that includes a code coverage tool. There are two options:

Jetbrains Rider¹. This has my preference. If you use Mac or Linux, you should use Rider. You can get free education license for this².
Microsoft Visual Studio Enterprise Edition. You need the _Enterprise It is a bit overkill, but smaller edition does not include any code coverage tool. Microsoft supposedly also offer an education license for

¹ https://www.jetbrains.com/rider/

² https://www.jetbrains.com/community/education/#students

Course Software Testing & Verification, 2020.

this^[1]. You can login with your Solis account. Unfortunately Microsoft also asks for your phonenumber, so if you don’t like this you should go with Rider.

For Unit Testing we will be using NUnit Testing Framework⁴, but your IDE should get this automatically when you read the project’s _.slnfile into the IDE.

You will also need a Code Metrics tool. An important metric is the McCabe/Cyclometic metric (Wikipedia gives an adequate explanation on this). If you use Rider you need to install the CyclomaticComplexity plugin. If you use Visual Studio for Windows, code metrics are already included.

2 The Game Logic

Name: STV Project PART 1 Solved
SKU: 50645
Price: 80.00 USD
Availability: InStock

The game logic is implemented by the classes in STVrogue.GameLogic. A large part of these classes are left unimplemented for you. And yes, you will also need to test them to make sure you deliver a correct game logic.

2.1 Class GameEntity

Monsters, items, rooms, and the player are the main entities of the game. They will have their own class, but they all inherit from a class called _GameEntity. We will insist that game entities (so, instances of _GameEntity) should have unique IDs. This is will be in particular important for PART-2 of the Project.

2.2 Class Dungeon

The game is played on a dungeon, which consists of rooms. There are three types of rooms: start-room, exit-room, and other rooms (we will call then ’ordinary’ room). A dungeon should have one unique start-room and one unique exitroom.

Rooms are connected with edges. If _ris a room, all rooms that are directly connected to r are called the _neighborsof r. The player and monsters can move from rooms to rooms by traversing edges. Technically, this means that the rooms in the dungeon form a graph whose edges are bi-directional. We require that all rooms in the dungeon are reachable from the start-node. Figure 1 shows some example of dungeons. The class Dungeon has two basic operations: 1. A constructor Dungeon(shape,N,γ) to create a dungeon consisting of _N_>2 rooms.

Keep in mind that a dungeon should satisfy the previously mentioned constraints about its connectivity and the uniqueness of its start and exit-rooms.

Figure 1. Some examples of dungeons: tree-shaped (left), linear dungeon (top right), and a dungeon which is neither treeshaped nor linear (bottom right).

The parameter _shapedetermines the shape of the dungeon. There are three types of shapes: _linear, tree, and _random. A linear-shaped dungeon forms a list with the start-room at one of its ends, and the exit-room at the other end.

A tree-shaped dungeon forms a tree with the startroom as the root. The exit-room should be a leaf of this tree.

A _randomdungeon can has any shape as long as it is not linear nor a tree.

Every room in the dungeon has a _capacity. If c is the capacity of a room _r, the number of monsters in _rshould not exceed _r. This capacity is a random value determined when the dungeon is created. For an ordinary room, it should be in [1_..γ]. Note that different rooms may thus have different capacity, but none will exceed the maximum capacity _γ. The start and exit-rooms always have capacity 0.
A method SeedMonstersAndItems(M,H,R) to randomly populate the rooms in the dungeon with monsters and items. There are two types of items: healing potion and rage potion.

The paramemer _Mspecifies the number of monsters to be dropped in the dungeon, _His the number of healing potions to be dropped, and _Ris the number of rage potions.

Populating the dungeon are subject to the requirements set below. Meeting these requirements are not always possible (e.g. it is not possible to populate a dungeon with _Nrooms whose capacities are at most k with (N ₋2)k monsters or more).

The method SeedMonstersAndItems returns true if it manages fullfill the requirements, else it returns false (and left the dungeon unpopulated).

Every monster in the dungeon should be alive and have HP and AR _>
Every room cannot be populated with more monsters than its capacity allows.
Let _Ebe the set of neighbor rooms of the exit-room. So: E = exitroom.Neighbors. Every room in E should be populated with more monsters than any non-E room. So, for anyr ∈ E andr^′< E, then |r.monsters| > |r^′.monsters| should hold.
Let _Nbe the number of rooms in the dungeon. At least ⌈_N_/2⌉ number of rooms should have no item at all.
Let I = startroom.Neighbors ∪ {startroom}. There should be at least one healing potion and one rage potion somewhere in _I.

2.3 Class Creature

A creature has _{hit point}(HP), attack rating, and its location

(the room it is in) in a dungeon. Attack rating should be a positive integer. A creature is _aliveif and only if its HP is _>0. There are two subclasses of Creature: _Monsterand _Player.

Creature has two operations: _move(r) to move it to a

neigboring room, subject to the room capacity, and _attack(f ) to attack another creature _fprovided it is located in the same room. When a creature_cattacks _f, the action will damage _f’s HP (that is, reducing it) by _∆where _∆is the attacker’s attack rating. If _f’s HP drops to 0, _fdies. A base implementation of these two operations are already provided, though you will have to override it for Player, e.g. because player moves are not constrained by rooms’ capacity.

The player has additionally ’Kill Point’ (KP) that is increased by one each time it kills a monster. The player also has a bag, that contains items it picked up.

2.4 Items

Items are dropped in the dungeon. When the player enters a room that contains items, it can pick them. The items will then be put in the player’s bag.

There are two types of items: Healing Potion and Rage Potion. A healing potion has some positive healing value.

When used, it will restore the player’s HP with this value, though the HP can never be healed beyond the player’s

HPMax.

A rage potion will turn the player into a raging barbarian. This temporarily double the player’s attack rating. The effect last for 5 turns (including the turn when it is used), though it also has some consequence that will be explained later.

Using a potion will consume it.

STV Project 2019/20, PART 1 Course Software Testing & Verification,

2.5 Class Game

The class provides the entry point to the game logic, and also holds most of the game logic^[2].

The constructor _Game(conf ) takes a configuration and will create a populated dungeon according to the configuration. The configurationconf is a record (shape,N,γ,M,H,R,dif ) of 7 parameters:

_shapethe shape of the dungeon to generate.
_Nthe number of rooms in the dungeon.
_γspecifies the maximum rooms’ capacity.
_Mis the number of monsters to generate.
_His the number of healing potion to generate.
_Ris the number of rage potion to generate.
_difis the difficulty mode of the game. There are three modes: Newbie-mode (easy), Normal-mode, and Elite

The constructor will generate a dungeon satisfying the parameters in _conf. Some configurations might be hard, or, as remarked in Section 2.2, even impossible to satisfy. The constructor should throw an exception if it fails, e.g. after several attemps, to generate a dungeon that satisfies the configuration.

All game entities in the generated dungeon should have unique IDs. The player should be alive, and its HP is equal to HPMax, and _>0. The player always starts at the start-room of the dungeon.

STV Rogue is a turn-based game. It means that the game moves from turn to turn, starting from turn 0, then turn 1, turn 2, etc. At a turn, every creature in the dungeon, and is still alive, makes one single action. The order is random, as long as everyone gets exacly one action. Between turns, the game state does not change.

The player wins if it manages to reach the dungeon’s exit-node. It loses if it dies before reaching it. The main API of the class _Gameis the method _update(α). This will iterate over all creatures in the dungeon as said above. A monster can choose its action randomly; this will be explained more below. The action of the player is as specified by _α(you can imagine that this _αrepresents a choice that the actual human player indicated through the game UI).

The player is _in-combatif it is in the same room with a monster. Likewise, a monster is in-combat if it is in the same room with the player.

There are six possible actions that a creature can do, though a monster can only do four of them:

DoNOTHING, it means as it says.
_MOVEr: the creature moves to another node r. This should be a neighboring node, and furthermore this should not breach _r’s capacity.

MOVE is _notpossible when the creature is in combat. The logic for executing this action is to be implemented in the method Game.Move(c,r), where c is the creature that moves.

_PICKUP: this will cause the player to pick up all items in the room it is currently at. The items will the be put in the player’s bag. A monster cannot do this action.
_USE_i: this will cause the player to use an item _i. The item should be in its bag. The effect of using different items were explained in Section 2.4. The logic for executing this action is to be implemented in the method Game.UseItem(i).
_ATTACKf : the creature attacks another creature f . This is only possible if both the attacker and defender are alive and are in the same room. Also, a monster cannot attack another monster. The logic for executing this action to be implemented in the method Game.Attack(c, f ), where c is the attacker and _fthe defender.
_FLEE: the creature flees a combat to a randomly chosen neighboring The conditions for when fleeing is allowed are a bit complicated. They are given below. When multiple conditions conflict, the condition that is listed first takes precedence (e.g. conditions c and d below may conflict; in such a situation we should follow c and ignore d).
A monster cannot flee to a room if this would exceed the room’s capacity.
The player cannot not flee to the exit-room.
In rooms neighboring to the start-room, the player can always flee.
After using a healing potion the player cannot flee at the next turn. So, if the the pot is used at turn _t, at turn _t₊1 it cannot flee (and since a creature can only do one action per turn, this implies that the player can’t flee in the same turn _teither). At turn _t₊2 will be able to flee.
The player cannot flee while ’enraged’. Recall that the player enters such a state when whenever it uses a rage potion (this state lasts for 5 turns, including the turn when the potion is used). However, this restriction does not apply when the game is played in the Newbie-mode.

If the game is played in the Elite-mode things become harder: if the player is enraged while in a room (let’s call it room _S) neighboring to the exit-room, the player will not be able to flee from _Seven after the rage effect has dissipated. Note that this does not mean that the player can never leave _S. It can do so by using the ordinary _MOVEcommand (which is only possible if it is no longer in combat). The logic for executing this action is to be implemented in the method _Game._Flee(c), where c is the fleeing creature.

3 The Main Class

The class STVrogue.Program is the main class (the class with the _Mainmethod) that provides the console application for the game. When you start the application, it reads the game configuration from a file (configuration is explained in Section 2.5). It shows a welcome-screen, and the game begins. At each turn the game should display at least:

The turn number.
Player information: HP and KP.
The id of the room the player is currently at, and those of connected rooms.
Ids of monsters in the room.
Items in the room.
Items in the player’s bag.
Avaialable actions for the player.

When the player does an action, print a message to the console informing the player of the effect of this action. When a monster in the current room does an action, also print similar message. Actions of monsters in other rooms should not be echoed to the console.

When the player wins or loses, print your ending message before exiting the game.

Right now the class STVrogue.Program contains a dummy implemetation just so that you can run it. Obviously, you should replace this dummy implementation with your own.

4 Important: Controlling Random

Like in many other games, some parts of STV Rogue are required to behave randomly (e.g. when generating dungeons, or when deciding monsters’ actions). When testing a program that behaves non-deterministically, the same test may yied different results when re-run with exactly the same inputs and configuration. Such a test is called ’flaky’ or ’unrepeatable’. Obviously we do not want to have flaky tests. To this end, you need to make it so that you can configure your implementation of STV Rogue to switch from using normal

random generators to using pseudo random generators when testing it^[3]. Such a generator behaves deterministically when given the same seed. Check the class _Utils._SomeUtilsto obtain such a generator.

5 Your Tasks

Your tasks are listed below. All are mandatory, except Task 8. You should divide the work among your team members such that everyone has her/his fair share of testing. In fact, the author of a functionality should not be the only person to test the functionality due to her/his obvious bias.

Move(r) and Creature.Attack(f ) (0.5 pt).
Dungeon(shape,N,γ) (1 pt). 3. Dungeon.SeedMonstersAndItems(M,H,R) (1 pt).
Game(conf ) (1 pt). 5. Game.Flee(c) (2 pt).
Finishing the implementation of STV Rogue (2 pt).
Test the rest of the game logic (1.2 pt).
Optional: stronger testing of _Flee(c) (1pt).
Report (0.3 pt).

All produced tests should deliver 100% code coverage^[4] on their test target (e.g., your tests on _Flee(c) should give 100% coverage on this method). If you deliver less, you have to explain the reason in your Report (e.g. because the uncovered parts are unreachable, or simply because you run out of time).

Please document your test methods and in-code specifications/parameterized-tests. Write a comment describing what each test method tries to check. Inside the body of each in-code specification/parameterized test, write a comment explaining what correctness properties different parts of the specification try to capture.

The McCabe/Cyclometic metric of your method should give a rough indicator of the minimum number of test cases you would need to test it. The metric gives the number of

’linearly independent’ control paths in the method (check Wikipedia’s entry on Cyclometic complexity).

5.1 Test Creature.Move(r) and Creature.Attack(f ) (0.5 pt)

To get you started in learning to do basic unit testing, test the above mentioned two methods to verify their correctness. The methods are already implemented, so you only need

[ T e s t F i x t u r e ]

p u b l i c c l a s s Test_Remainder { / / the t e s t s :

[ TestCase ( 5 , 0 ) ]

[ TestCase ( 5 , 3 ) ]

[ TestCase ( 5 , ₋3 ) ]

[ TestCase ( ₋5 , ₋3)]

. . .

/ / the in ₋code spec . f o r % : p u b l i c void Spec_Remainder ( i n t x , i n t y ) {

/ / check the method₋under₋t e s t ‘ s pre ₋c o n d i t i o n :

if ( y != 0 ) {

/ / c a l l i n g the method₋under₋t e s t :

i n t r = x % y

/ / ( a ) check the method ‘ s post ₋c o n d i t i o n : r i s a c o r r e c t

/ / reminder _ifi t i s e qual to x ₋d ∗ y , where d i s the / / r e s u l t of d i v i d i n g x with y :

A s s s e r t . I s t r u e ( r == x ₋( x / y ) ∗ y ) ;

}

else {

/ / ( b ) the method should throw t h i s e x c e p t i o n when i t s / / pre ₋c o n d i t i o n i s not s a t i s f i e d :

A s s e r t . Throws < DivideByZeroException >( x % y ) ;

}

STV Project 2019/20, PART 1 Course Software Testing & Verification,

Figure 2. An example of how to write an NUnit test through an in-code specification. Let’s imagine we want to test C# remainder operator (%).

to test them (and to fix them if you find bugs). Use NUnit Framework to write your tests.

5.2 Implement and test the constructor Dungeon(shape,N,γ) (1 pt)

The intended behavior of this constructor is informally specified in Section 2.2. Implement the constructor. Then, formalize its informal specification as an in-code specification and then use NUnit parameterized test to test the method. Figure 2 shows an example of how to do this. The class Utils.HelperPredicates contains some help pred-

icates you might find useful.

5.3 Implementation and test Dungeon.SeedMonstersAndItems(M,H,R) (1 pt)

The intended behavior of this constructor is informally specified in Section 2.2. Implement it and write in-code specification for the method. This time, formulate the in-code specification as NUnit _Theoryand then test that Theory.

Check NUnit Documentation: https://github.com/nunit/ docs/wiki/NUnit-Documentation . The entry about Theory should be listed under the category ’Attributes’. There is also an example of using Theory in the STV Rogue project itself.

5.4 Implementation and test the constructor Game(conf ) (1 pt)

The intended behavior of this constructor is informally specified in Section 2.5. Implement the constructor and write in-code specification for this method. Formulate it as a parameterized test. This time, use NUnit combinatoric testing feature to generate tests for the constructor. Be mindful that full combinatoric test may blow up to thousands of test cases. You may want to consider pair-wise testing instead.

Check the entries on ’Combinatorial’ and ’Pairwise’ in NUnit documentation. There are also examples of these in the STV Rogue project itself.

5.5 Implementation and test the method Game.Flee(c) (2 pt)

The intended behavior of this method is informally specified in Section 2.5. This method has the most complicated logic. Implement and test it.

5.6 Finish the Implementation of STV Rogue (2 pt) Finish the implementation of STV Rogue to get a working game. Among other things, you will have to implement the method Game.Update(cmd) as well as finishing the main class Program.

5.7 Test the rest of the game logic (1.2 pt)

Finish the testing of the game logic (that is, of all classes in the STVrogue.GameLogic namespace).

5.8 Optional: stronger testing of Flee(c) (1pt)

The logic of the method _Dungeon._Flee(c) is fairly complicaated. For such a method simple code coverage does not really reflect the adquacy of your tests as it cannot enforce path-level verification. Unfortunately there is no tool in the market that will let you do path coverage tracking. Let us try to compensate this by augmenting your existsing tests for _Fleewith combinatoric testing. Chapter 4 in Ammann & Offutt’s book (Ch. 6 for 2nd Ed.) explains the main concepts. See also the slides from Week-2.

Identify the set of ’characteristics’ on which the behavior of _Flee(c) depends on. These typically include the method parameters (there is only one: _c), but also other aspects that are not formally listed as a parameter, e.g. the location of _c, the use of healing potion, the difficulty-mode, etc.

Then, decide how you want to partition each characteristic into ’blocks’. E.g. _ccan be a monster or the player (so, we would have two blocks for _c). The position of _ccan be distinguished between: a neighbor of the start-room, a neighbor of the exit-room, or other room. The used difficulty-mode can be distinguished between: the newbie-mode, the normalmode, or the elite-mode. And so on.

Translate your design into an NUnit combinatoric (or at least pair-wise) test using a parameterized test.

5.9 Report (0.3 pt, mandatory) Make a report containing the items listed below.

The general statistics of your implementation:

N =
M ₌total #methods	:	…
locs ₌total #lines of codes(*)	:	…
locs_avд= average #lines of codes(*)	:	locs/N

total #classes : …

(*) exclude comments 2. Statistics of your unit-testing effort:

N^′₌#classes targeted by your unit-tests : … total coverage over _GameLogic: … T ₌#test cases (*) : … Tlocs ₌total #lines of codes (locs) of your unit-tests : …

Tlocs_avд= average #unit-tests’ locs per target class : Tlocs/N^′

E ₌total time spent on writing tests : … E_avд= average effort per target class : E/N^′total #_bugsfound by testing : …

Statistics of some selected targets

Dungeon(shape, N, γ)