tP:
Admin Appendix E(extract): Workflow (after v1.2)
After following the given workflow for at least i.e., until the end of v1.2one iteration, optionally, you may adjust the process rigor to suit your team's pace. Here are some examples:
Reduce automated tests: Automated tests have benefits, but they can be a pain to write/maintain.
It is OK to get rid of some of the troublesome tests and rely more on manual testing instead. The less automated tests you have, the higher the risk of regressions; but it may be an acceptable trade-off under the circumstances if tests are slowing you down too much.
There is no direct penalty for removing tests. Also note our expectation on test code.
Reduce automated checks: You can also reduce the rigor of checkstyle checks to expedite PR processing.
Switch to a lighter workflow: While forking workflow is the safest (and is recommended), it is also rather heavy. You may switch to a simpler workflow if the forking workflow if you wish. Refer the textbook to find more about alternative workflows: branching workflow, centralized workflow. Even if you do switch, we still recommend that you use PR reviews, at least for PRs affecting others' features.
If you are unsure if a certain adjustment is allowed, you can check with the teaching team first.
🤔 How much testings is enough? We expect you to decide. You learned different types of testing and what they try to achieve. Based on that, you should decide how much of each type is required. Similarly, you can decide to what extent you want to automate tests, depending on the benefits and the effort required.
There is no requirement for a minimum coverage level. Note that in a production environment you are often required to have at least 90% of the code covered by tests. In this project, it can be less. The weaker your tests are, the higher the risk of bugs, which will cost marks if not fixed before the final submission.
The version you deliver in this iteration (i.e., v1.3) will be subjected a peer testing (aka PE Dry Run) and you will be informed of the bugs they find (no penalty for those bugs). Hence, it is in your interest to finish implementing all your features you want to include in your final version (i.e., v1.4)final features in this iteration itself so that you can get them tested for free. You can use the final iteration for fixing the bugs found by peer testers.
Furthermore, the final iteration (i.e., the one after this) will be shorter than usual and there'll be a lot of additional things to do during that iteration e.g., polishing up documentation; all the more reason to try and get all the implementation work done in this iteration itself.
As you did in the previous iteration,
In addition,
Why the hurry to update documents? Why not wait till the implementation is finalized?
We want you to take at least two passes at documenting the project so that you can learn how to evolve the documentation along with the code (which requires additional considerations, when compared to documenting the project only once).
Wt is better to get used to the documentation tool chain early, to avoid unexpected problems near the final submission deadline.
It allows receiving early self/peer/instructor feedback.
AB3 uses PlantUML (see the guide Using PlantUML @SE-EDU/guides for more info).
You may use any other tool too (e.g., PowerPoint). But if you do, note the following:
Choose a diagramming tool that has some 'source' format that can be version-controlled using git and updated incrementally (reason: because diagrams need to evolve with the code that is already being version controlled using git). For example, if you use PowerPoint to draw diagrams, also commit the source PowerPoint files so that they can be reused when updating diagrams later.
Can i.e., automatically reverse engineered from the Java codeIDE-generated UML diagrams be used in project submissions? Not a good idea. Given are three reasons each of which can be reported by evaluators as 'bugs' in your diagrams, costing you marks:
0..1
vs 1
, composition vs aggregation*Command
classes using a placeholder XYZCommand
).ref
frames to break sequence diagrams to multiple diagrams. Similarly, rake
s can be used to divide activity diagrams.These class diagrams seem to have lot of member details, which can get outdated pretty quickly:
In this negative example, the text size in the diagram is much bigger than the text size used by the document:
It will look more 'polished' if the two text sizes match.
delete
command
3
participation points. Please do it before the deadline.Some background: As you know, our i.e., Practical ExamPE includes peer-testing tP products under exam conditions. In the past, we used GitHub as the platform for that -- which was not optimal (e.g., it was hard to ensure the compulsory labels have been applied). As a remedy, some ex-students have been developing an app called CAT stands for Crowd-sourced Anonymous TestingCATcher that we'll be using for the PE this semester.
This week, we would like you to smoke-test the CATcher app to ensure it can run in your computer.
The steps for smoke-testing CATcher:
More Info
link in the security warning and choose Run anyway
).CS2103/T Alpha Test
, and submit.
alpha
in your GitHub account, when it asks for permission. That repo will be used to hold the bug reports you will create in this testing session.severity
and type
labels are compulsory.alpha
repo created by CATcher in your GitHub account (keep it until the end of the semester) as our scripts will look for it later to check if you have done this activity.v1.2.1
(or v1.3.trial
). Ensure that the jar file works as expected in an empty folder and using Java 11, by doing some manual testing. Reason: You are required to do a proper product release for v1.3. Doing a trial at this point will help you iron out any problems in advance. It may take additional effort to get the jar working especially if you use third party libraries or additional assets such as images.