MILESTONE - Basic Unit Testing

[jeturcotte]

Right, so now let's change focus for a bit and introduce some unit testing to our proto-application before we get too far in and lose our minds trying to do testing for ALL of it. Particularly savvy outfits often write tests FIRST (before any code) to help guide developers to producing the intended product, but also to basically document the whole idea. That's a level of sophistication most places don't achieve, tbh... but is wonderful to behold when it is in place. (full disclosure... I've yet to do it myself, but sure would like to.)

• RESEARCH: Learn about unit testing (in general / via raku).
  • https://docs.perl6.org/language/testing seeeeeems like a good start, as a basic built in testing layer for perl6/raku overall.
  • Quickly see if anyone in the community has built out a more fully featured one, just for informational purposes.
• TASK: Test the internal non-visible guts of the application as it currently stands
  • Write a test that verifies that the application is responding at all.
    • This might include ADDING an API endpoint to the application that acts as a 'heartbeat' ... when you call it the server responds saying basically either 'yep, I'm running' or doesn't respond, and therefore is broken. Then add the test to simply check for this heartbeat and pass the test on correct response.
• TASK: Test the creation of an account ( re: MILESTONE -- Registration #6 ) and account verification (re: MILESTONE -- Account Verification #10 )
  • Ensure that submitting all the needed data results in a successfully created account
  • Ensure that submitting insufficient data results in an error response from the server
  • Ensure that submitting the wrong kind of information results in an error from the server
• TASK: Test the usefulness of authentication ( re: MILESTONE - Authentication #7 )
  • Ensure that submitting an authentication attempt with the correct credentials results in being 'logged in'
  • Ensure that submitting incorrect authentication details will result in a rejection
  • LATER, when we have more screens that should ONLY be accessible to authenticated individuals, we will test that they CANNOT be reached without it (but that's later.)

Note the above of somewhat vague in part because I still need to catch up with what you've done and in part because you should try to asses what would make a good test. Still, if you look at the code and see a function that does a specific thing, it's a good subject for testing.

Ask questions (preferably in the comments.)

[ajbuchholz]

Ok. So you would like us to start testing the application and documenting this? I am slightly confused as too what you would like us to do this afternoon and Thursday. We were planning on beginning documentation for CRO. If you have the time to create a checklist like in other issues we would greatly appreciate that.

[jeturcotte]

I'm writing it out still... it'll show up here as I save incrementally save it

[jeturcotte]

Don't abandon cro docs in the meantime

[ajbuchholz]

Got it.

[ajbuchholz]

We have been looking into test-driven development. So far we generally understand it because of its similarities to Doctest with python. We hope to see you tonight!

[jeturcotte]

note: https://dev.to/lancew/tdd-and-cro-in-perl6-land-20g1

[jeturcotte]

How'd things go the last week?