You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@dhermes Maybe. This one makes it a goal to document how we do functional tests (but maybe not to actually write any?).
There is some jargon skew between "functional" / "regression" / "integration" testing. For instance, I consider that adding a unit test which fails before fixing a bug could be called "regression" testing, as it ensures that the fix is not accidentally undone later. From conversations with @silvolu, I believe he uses "regression test" to refer to tests which actually exercise the server API, versus the unit tests which stub / mock it.
I contemplated writing a sample app which would serve both as the basis for narrative docs and as a possible set of regression tests (see my preliminary sketch).
@tseaver I should probably say "regression testing done with functional tests" :)
What I mean is to ensure that changes tested only against mocks have not introduced new faults in the core set of functionalities by testing them against the real API. @dhermes this issue is mostly a placeholder, you (or I) can open a new one if you want.
Activity
dhermes commentedon Sep 23, 2014
@tseaver This is the bug you were referring to for me to claim and do the regression test work in?
tseaver commentedon Sep 23, 2014
@dhermes Maybe. This one makes it a goal to document how we do functional tests (but maybe not to actually write any?).
There is some jargon skew between "functional" / "regression" / "integration" testing. For instance, I consider that adding a unit test which fails before fixing a bug could be called "regression" testing, as it ensures that the fix is not accidentally undone later. From conversations with @silvolu, I believe he uses "regression test" to refer to tests which actually exercise the server API, versus the unit tests which stub / mock it.
I contemplated writing a sample app which would serve both as the basis for narrative docs and as a possible set of regression tests (see my preliminary sketch).
silvolu commentedon Sep 24, 2014
@tseaver I should probably say "regression testing done with functional tests" :)
What I mean is to ensure that changes tested only against mocks have not introduced new faults in the core set of functionalities by testing them against the real API.
@dhermes this issue is mostly a placeholder, you (or I) can open a new one if you want.
dhermes commentedon Sep 25, 2014
Yeah I think this issue is just fine. As mentioned I'm tracking this in a dirty branch but hope to get real reviewable code soon.
dhermes commentedon Oct 22, 2014
#281 also chipping away at this
dhermes commentedon Nov 6, 2014
@silvolu As of #319 landing I am calling this "done".
Re-open if you feel it's necessary.
Merge pull request googleapis#106 from jgeewax/koss-vtk-code
Merge pull request googleapis#106 from Psynbiotik/SaveTokenPath
98 remaining items
chore(deps): update precommit hook pre-commit/pre-commit-hooks to v3.…
fix: remove setup.cfg configuration for creating universal wheels (#106)
fix: avoid 404 if dataset is deleted while listing tables or views (#106
chore: release 0.5.1 (#92)
chore: [autoapprove] update readme_gen.py to include autoescape True (#…
refactor: drop six package use (#106)
fix: remove duplicate stream handler (#106)
port/correct remaining docs and start narrative effort (#106)
Refactor common code from google.oauth2.flow to google.oauth2.oauthlib (
ci: add a job to build manylinux1 wheels at release (#106)
feat: add raw download classes (#109)
fix: rollback failed exception log (#106)
chore: release 1.0.0 (#167)
fix(storage): remove expiration strict conversion (#106)
ci: add a job to build manylinux1 wheels at release (#106)