Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add --is-test to all test commands #61

Open
sbillinge opened this issue May 15, 2024 · 9 comments
Open

add --is-test to all test commands #61

sbillinge opened this issue May 15, 2024 · 9 comments
Milestone

Comments

@sbillinge
Copy link
Contributor

90% of tests will pass without the --is-test flag set, but for consistency, I suggest we add this to all the tests. It will create less confusion in the future .

@sbillinge sbillinge added this to the Release 0.1.0 milestone May 15, 2024
@stevenhua0320
Copy link

UC 1 Tester of LPP test the app runs successfully

  1. Tester of app runs LPP and set --is-test to True
  2. A tester uses particular test files to determine if corresponding functions run without errors or potential bugs.

@sbillinge
Copy link
Contributor Author

UC 1 Tester of LPP test the app runs successfully

1. Tester of app runs LPP and set --is-test to True

2. A tester uses particular test files to determine if corresponding functions run without errors or potential bugs.

sorry, this is all very confusing. We don't need a UC for the tests. We are looking for pseudocode of the actual test functionality. Sorry it is so confusing. Thank you so much for your efforts to understand. I know it is confusing. UCs capture user behavior (no implementation information), pseudocode for hte test describe the actual code that will be written but not in real syntax.

@sbillinge
Copy link
Contributor Author

Here is an example of pseudocode for the test.

def test_apply_correction():
    set current time to midnight 1st Jan 2024 using runfreeze
    actual = apply_correction(inputs, now)
    expected = get_args(set test bool)
    expected.creation_time = midnight 1st Jan 2024
    assert actual.creation_time = expected.creation_time

something like that.

@stevenhua0320
Copy link

OK, so for --is-test, since it is not for general users, here we directly consider its test function to consider its behavior right?

@sbillinge
Copy link
Contributor Author

alternatively, since a goal is for that creation time to actually appear in the file, we could write a file and then check that the right time is in there.

On the whole, I think if we check that the right thing is loaded in args, and then later we make a test that checks that everything from args makes it into the file, this accomplishes the same thing

@sbillinge
Copy link
Contributor Author

OK, so for --is-test, since it is not for general users, here we directly consider its test function to consider its behavior right?

I am afraid I don't understand your question. We may not need --is-test here actually if we use runfreeze.

@stevenhua0320
Copy link

Yes, that's what yucong and I previously thought about since for creation-time we may not use --is-test since we use freezegun to freeze time to test the datetime behavior. but for other cases, we might still use --is-test flags, so we might use it elsewhere.

@sbillinge
Copy link
Contributor Author

Yes, that's what yucong and I previously thought about since for creation-time we may not use --is-test since we use freezegun to freeze time to test the datetime behavior. but for other cases, we might still use --is-test flags, so we might use it elsewhere.

in that case it is not needed in this PR at all.

@sbillinge
Copy link
Contributor Author

Let's hold on this until we are sure it is needed. It is not something i want unless it is absolutely needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants