Move testing data to tests #5

New Issue

plaes · 2020-12-23T11:49:27Z

plaes commented

2020-12-23 11:49:27 +00:00

Most of the modules where some kind of parsing occurs ( listServers.py / prom.py / prom_servers.py ... ) contain commented out data for parsing test (or even functionality).

Would be nice if this data is actually called from the unittest framework
https://docs.python.org/3/library/unittest.html

Most of the modules where some kind of parsing occurs ( `listServers.py` / `prom.py` / `prom_servers.py` ... ) contain commented out data for parsing test (or even functionality). Would be nice if this data is actually called from the unittest framework https://docs.python.org/3/library/unittest.html

rasmus referenced this issue

2020-12-23 18:44:10 +00:00

Make code modular. #6

rasmus commented

2020-12-25 03:42:16 +00:00

DRAFT

Yep, I thought of tests as well.

I looked at unittest, I have a few questions. I haven't done any more surveying yet.

I'd assume tests go in a separate folder. Tests import other files, and run their functions..?

As for test data: test data in, processed data out almost seems like a waste of time. Each time the code being tested is changed, the test needs to be updated. Only case I could see this useful would be emulating the SSH endpoint, or possibly catch ssh_runcmd, and return a testing data ('cached') response.
Rather, test data comes useful when adding new functions, or modifying existing ones. Yet again, 'caching' the previous thing's reply, speeding up my own live testing.
If I need to add the changing test data frequently to a separate file, I'd rather add commented var=. It's clearer (as you don't have to refer elsewhere), and quicker. I understand that the codebase looks better, but if it practically hinders me, and others, I'd rather not use it.

Calls testing data.

Adding data = testdata, what only runs if ENV var is set would probably be beneficial, as it lowers the possibility for human error. Though, it seems, that you still have to manually switch, and add data. Additionally, it seems that you can't test 2 separate things together (everything one-by-one, or at once).

I'd really like to see opportunistic automatic caching (think of Dockerfile).

writing own sdajls to do tests sounds like a dumb idea

something other I don't remember
walking back in to myself, text doesn't fall out well

DRAFT *** Yep, I thought of tests as well. I looked at unittest, I have a few questions. I haven't done any more surveying yet. I'd assume tests go in a separate folder. Tests import other files, and run their functions..? As for test data: test data in, processed data out almost seems like a waste of time. Each time the code being tested is changed, the test needs to be updated. Only case I could see this useful would be emulating the SSH endpoint, or possibly catch ssh_runcmd, and return a testing data ('cached') response. Rather, test data comes useful when adding new functions, or modifying existing ones. Yet again, 'caching' the previous thing's reply, speeding up my own live testing. If I need to add the changing test data frequently to a separate file, I'd rather add commented var=. It's clearer (as you don't have to refer elsewhere), and quicker. I understand that the codebase looks better, but if it practically hinders me, and others, I'd rather not use it. > Calls testing data. Adding data = testdata, what only runs if ENV var is set would probably be beneficial, as it lowers the possibility for human error. Though, it seems, that you still have to manually switch, and add data. Additionally, it seems that you can't test 2 separate things together (everything one-by-one, or at once). I'd really like to see opportunistic automatic caching (think of Dockerfile). writing own sdajls to do tests sounds like a dumb idea something other I don't remember walking back in to myself, text doesn't fall out well

Sign in to join this conversation.

No Label

No Milestone

No Assignees

2 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: rasmus/blades-ssh-scraper#5