search

AuburnACM / auacm

The Auburn ACM Website
Apache License 2.0
15 stars 3 forks source link

Testing #23

Closed WilliamHester closed 8 years ago

WilliamHester commented 9 years ago

Pretty much everything needs a unit test associated with it. Some integration testing wouldn't hut. TDD all the way, baby.

BrandonLMorris commented 8 years ago

Any ideas how we wanna go about this? I know @djshuckerow has started some unit tests for the judge, is that what we want to focus on? I know there's a package called Selenium that does web browser automation and is used for web testing. There's also something called RobotFramework that I'll be using at Adtran this spring; that may be something useful.

tl;dr I have no idea what I'm doing.

BrandonLMorris commented 8 years ago

Btw, what kind of coverage are we shooting for?

DaveShuckerow commented 8 years ago

Generally, you'll want to focus on anything that, if it fails, the site will be "broken" in some way, like a competition not working at all or the like.

Coverage should be similar; anything that's application-critical should be protected by tests. I don't know the exact details, but the judge, logic that governs the beginning and end of competitions, and anything else that has to work should be protected by tests that guarantee that it will work the way that it's supposed to.

If you're looking for ways to do frontend tests, I'd start with a javascript unit test framework and just test the frontend logic; UI testing is more expensive in terms of time and complexity, and most UI defects can be noticed more easily by a human user than logical errors in the code. UI tests can be valuable, but unit tests are usually more useful and they're low-hanging fruit.