serg-delft / jpacman-framework Goto Github PK

Hello !! My name is Pedro and I am from Oporto,Portugal.I am currently in the 3rd year of the course of Computer Engineering at FEUP( Engineering College of University of Oporto ) and im doing a work for a class named Software Engineering( ESOF) tha basically consists in studying a open source project avayable on Github. I would like to know if someone could talk me about jpacman testability and how hard or no is to build tests for jpacman and what are the big concerns about testing jpacman functionallity.

Thanks a lot and sorry for any problem i may had cause here.

The Framework's Cucumber features and step definitions are part of the test jar, which is imported in the template. This has the effect that the same step definitions also apply in solutions based on the template, which is counter intuitive.

A solution might be to drop the test jar dependency in the template.

The 'workaround' now is

1. To use a uniquely named feature folder in the solution
2. To shadow nl.tudelft.jpacman.cucubmer.StateNavigationSteps by having that same package/class in the solution.

http://docs.travis-ci.com/user/migrating-from-legacy/

If a user tries to parse a map without putting a player on that map, an IndexOutOfBoundsException will be thrown. This exception doesn't tell the user anything about his possible error. It would be better to throw a PacManConfigurationException, because this will tell the user what is going wrong, and gives an indication as to how this problem can be fixed.

I want to make a quick PoC for mutation testing with pitest.
Would it be interesting to include this in the main repository?

For now I'm using and configuring it via Maven.

Imported from GitLab, original author: @LiamClark

Mockito now ships an extension as support for JUnit 5.

We should add this as a dependency to use for students. This also allows us to finally drops the dependency on JUnit 4.

Removing JUnit 4 from the project will eliminate a set of errors, due to mixing JUnit 4 and JUnit 5 imports.

Cobertura is not able to parse any Java 8 statement and Jacoco seems to be a good replacement. Therefore we should remove Cobertura.

However, as @jwgmeligmeyling pointed out, DevHub still uses Cobertura for the warning system. We therefore need to wait till DevHub is updated before removing this plugin.

JPacman currently works with the checkerframework, which presently is not ready for jdk9.

See typetools/checker-framework#1224

We need to update the pom.xml file so that mvn verify passes for the jpacman-framework, also when jdk 9 is used.

I have started working on this -- see PR #99.

The mvn site configuration uses the newer maven 3 configuration.

The recommended configuration, however, is to use the 'classic' maven 2 + 3 configuration, as explained on the maven site plugin documentation.

There appears to be a dependency resolution issue with JUnit. Cucumber 1.2.4 requires JUnit 4.11, whereas the framework requires JUnit 4.12.

There seem to be two possible solutions:

1. Exclude the JUnit dependency on Cucumber in the pom.xml
2. Bump cucumber to version 1.2.5-SNAPSHOT which does depend on JUnit 4.12 (originally junit 4.12 broke compatibility with android) See #82 (comment)

The mvn javadoc:javadoc still gives warnings -- these need to be fixed.

Does anybody else get the same problem when executing mvn site?

[INFO] Generating "Checkstyle" report --- maven-checkstyle-plugin:2.12
[INFO]
[INFO] Generating "FindBugs Report" report --- findbugs-maven-plugin:2.3.2
[INFO] canGenerate is true
[INFO] canGenerate is true
[INFO] Locale is en
[INFO] ****** FindBugsMojo executeReport *******
[INFO] XML outputFile is /home/mbeller/Preaching/jpacman-framework/target/findbugsXml.xml
[INFO] XML output Directory is /home/mbeller/Preaching/jpacman-framework/target
[INFO] ****** FindBugsMojo executeFindbugs *******
[INFO] Temp File is /home/mbeller/Preaching/jpacman-framework/target/findbugsTemp.xml
[INFO] Fork Value is true
[java] Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 35328
[java] at org.objectweb.asm.ClassReader.accept(Unknown Source)
[java] at edu.umd.cs.findbugs.asm.FBClassReader.accept(FBClassReader.java:44)
[java] at org.objectweb.asm.ClassReader.accept(Unknown Source)
[java] at edu.umd.cs.findbugs.classfile.engine.ClassParserUsingASM.parse(ClassParserUsingASM.java:93)
[java] at edu.umd.cs.findbugs.classfile.engine.ClassParserUsingASM.parse(ClassParserUsingASM.java:414)
[java] at edu.umd.cs.findbugs.classfile.engine.ClassInfoAnalysisEngine.analyze(ClassInfoAnalysisEngine.java:65)
[java] at edu.umd.cs.findbugs.classfile.engine.ClassInfoAnalysisEngine.analyze(ClassInfoAnalysisEngine.java:39)
[java] at edu.umd.cs.findbugs.classfile.impl.AnalysisCache.getClassAnalysis(AnalysisCache.java:214)
[java] at edu.umd.cs.findbugs.ba.XFactory.getXClass(XFactory.java:581)
[java] at edu.umd.cs.findbugs.ba.AnalysisCacheToAnalysisContextAdapter.setAppClassList(AnalysisCacheToAnalysisContextAdapter.java:319)
[java] at edu.umd.cs.findbugs.FindBugs2.createAnalysisContext(FindBugs2.java:785)
[java] at edu.umd.cs.findbugs.FindBugs2.execute(FindBugs2.java:187)
[java] at edu.umd.cs.findbugs.FindBugs.runMain(FindBugs.java:348)
[java] at edu.umd.cs.findbugs.FindBugs2.main(FindBugs2.java:1057)
[java] Java Result: 1
[INFO] No bugs found
[INFO] Generating "Surefire Report" report --- maven-surefire-report-plugin:2.17

Written in scenarios.md is:

Scenario S3.2: The ghost moves over food.
Given the game has started,
and a ghost is next to a cell containing food;
When a tick event occurs;
Then the ghost can move to the food cell,
and the food on that cell is not visible anymore.

However, I can not seem to find an implementation of food anywhere in the framework, are pellets meant with "food" ?

Imported from GitLab, original author: [hidden-student]

In the javadoc of Inky it says inky has the bug from the original pacman. This is the bug where if pac-man looks up the spot used for pinky his new location is 2 squares away from pacman to the north and to the west. However this is not correctly implemented and the spot is just 2 squares to the north.

PMD 6 has re-organized its rule sets, making the old PMD categories JPacman used obsolete.

PR #120 just re-added the best practices, but it would be better to rethink all rules used, and to update the pmd-rules.xml file accordingly.

This relates to the (lack of) JUnit 5 rules for PMD.

Just tossing around the thought for improvement next year: migrate the framework (and template alike) to Gradle.

Why?

Running mvn site on the template, the jacoco report does not correctly generate code coverage for the framework. There are various solutions for that in Gradle, which do not exist in maven.
Moreover, Gradle is usually easier to read and more maintainable as well as widely used in recent industry projects.

Regarding editor support: IntelliJ has nice integration for Gradle on every OS, just like it has for mvn.

Make the MapParser.addSquare method protected instead of private, so that extensions can reuse the existing map actions.

In our [scenarios.md] (https://github.com/SERG-Delft/jpacman-framework/blame/master/doc/scenarios.md#L94) file we mention that scenario 2.5 extends 2.1.

Most students think the extends word is some sort of cucumber keyword and expect the feature to automatically get the steps from 2.1. This is however not the case. We actually expect them to put the relevant steps from 2.1 into 2.5. Any suggestions to make this terminology less confusing?

Currently, incorrect configuration can throw IOException and IllegalArgumentException, which in some cases are wrapped into RuntimeException.

My proposal is to introduce one top level checked PacmanConfigurationException, which can replace/wrap the existing exceptions.

/cc @rsouzacoelho

In the case that a pallet collides with a player the PlayerCollisions and DefaultPlayerInteractionMap react differently.

The PlayerCollisions CollisionMap will do nothing while the DefaultPlayerInteractionMap will instead act as if the player collided with a pallet.

Imported from GitLab, original author: @LiamClark

The annotations are needed to suppress spot bugs warnings. However provided dependencies are not transitive.

Now students will have to copy paste the dependency