Feature/test cases #89
Conversation
|
@sapradhan Could you please kindly review my new updates ?? |
|
looks good to me, much needed testing. is there a way to repeat test say 10-20 times, regenerate the output as well? |
|
Yes absolutely, in my fork I have integrated GitHub actions to run this test 10 times and produce output. Link Here:- I am not sure if actions will run in the main repo if it will I will modify the actions and push it to the main repo. |
Probably will create a new issue to implement this later if this PR is merged |
|
a bit skeptical about dont think the way skipping that test but merging as a lot of PRs are blocked because of lack of tests |
Understood. I will work on a more optimised code to tackle those test cases. |
In my previous commits I had added individual test cases to very for each less preferred allocation. For which reason was assumed as a unique type But I was made aware that the reason column is an open text field. Hence I generalised the logic for any combinations of less preferred to be flagged as fail. Can we assume the reason column to be a classifier or have a seperate column as a reason type ?
In that way we can customise tests for each reason. |
|
the test should simply check for each row in output file if there is a preference score it should be > PREF_CUTOFF |
| return reader | ||
|
|
||
| def get_columns(self): | ||
| with open(self.file_path, "r", newline="", encoding="utf-8") as file: |
There was a problem hiding this comment.
It would be nice not to open and close files everywhere in the code; this means that the testing will be pretty cumbersome. Not to mention the repetitions. This also leads to multiple opportunities for executing files all over the code more open doors for executing malicious file. I would like to know the rationale behind it. IO should be done only once as a data input, not wherever we can. Also, since the data size is small, we can load it in memory and pass it along so we don't have to worry about th reader being exhausted.
I think this TSV parser could be reformatted if we really need one; otherwise, just a couple of functions would have done the job.
class TsvFileParser:
def __init__(self, file_path):
self.file_path = file_path
self.parsed_data : YourType = None
def parse(self, ..) -> None:
try:
with open(self.file_path, "r", newline="", encoding="utf-8") as file:
reader = csv.DictReader(file, delimiter="\t")
except YourException as e:
# log, exit depending on the need, and inform the user or raise with custom exception handled elsewhere. But logging, exiting, and telling the user should be enough here.
data = []
for row in reader:
data.append(row)
self.parsed_data = data
return self
tsv_parser = TsvFileParser(lovely_file_name)
parsed_data = tsv_parser.parse().parsed_data
or
tsv_parser.parse()
parsed_data = tsv_parser.parsed_dataThere was a problem hiding this comment.
Agreed will optimise this code in my Next PR
| data.append(row) | ||
| return data | ||
|
|
||
| def get_column_data(self, column_name): |
There was a problem hiding this comment.
These seem unnecessary functions; it would be good to not add any functions that we don't need. This becomes unmanageable down the line and then we have functions that don't have tests also which is going to be pretty heavy for anyone to manage these
There was a problem hiding this comment.
I beg to differ though. These functions are decoupled and maintained inside utils. In this way we have many other objects inherit the same functionality with less repeated code.
There was a problem hiding this comment.
Hmm, are we sure that this function is used elsewhere? Otherwise, leaving around unused and untested functions is a relatively bad idea.
| os.remove(self.school_center_distance_file) | ||
|
|
||
| def test_results_exists(self): | ||
| """_Test if the application in running which output the results in the |
There was a problem hiding this comment.
The test name should be descriptive enough so that one doesn't need to write any comments, if one needs to write a comment for a function/test, then usually there is a smell; it might not be the case here, but I think the descriptive test would be better off even looking at the console.
There was a problem hiding this comment.
I am using the python auto-doc string so just writing the comment to stick to consistency makes it easier for autoamated documentations later on. I can remove it but basically its checking if the output file exisits or not :).
| PREF_CUTOFF = -4 | ||
|
|
||
|
|
||
| def get_scode_cscode_id(data): |
There was a problem hiding this comment.
Is this function just for this test or could have been used in the actual code ?
There was a problem hiding this comment.
This is one of the helpers for the test. Not very proud of what I have done but its a make shift hashmap or dictionary to identify collisions in centers and schools.
There was a problem hiding this comment.
Could we make it private or mark it as the fixture with pytest ?
| return school_centers | ||
|
|
||
|
|
||
| class TestSchoolCenter(unittest.TestCase): |
There was a problem hiding this comment.
Project intends to use pytest, but for some reason these tests are written in unittest 🤔
There was a problem hiding this comment.
I can convert it to pytest later on but pytest should be able to run unittests as well with no issues
There was a problem hiding this comment.
Yes, it would be great to use pytest as it brings a lot of power to fixtures management and testing.And, it's not about pytest being able to run unit tests; it's more of the above and consistency. Also, the fact that we intend to use pytest, so it would be nice not to have the disparity. But all good, one step at a time ✅
Summary
Pull request type
Please tick the type of change your PR introduces:
What is the current behaviour?
Currently there is no Tests to validate/ accept that the feature submission is passing the acceptance criteria.
Issue Number: #4
Checklist
Please review and complete the following checklist before submitting your pull request:
Other information