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

CBL-3341: Review and Complete Collection Tests #101

Merged
merged 4 commits into from
Jul 12, 2022
Merged

Conversation

LaurenNguyen14
Copy link
Contributor

  • CBL-3357: Validate 32+ select items in the query fails or not
  • Fix the error code for getting documents from a deleted collection

CBL-3357: Validate 32+ select items in the query fails or not
Copy link
Contributor

@bmeike bmeike left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks great.

I've left some comments but the most important one is that I'd like you to use the name randomizer whenever you create something that might conflict with the next test. We had a lot of trouble, in the past, with one test failing and causing a cascade of other tests to fail, because the failing test left cruft around.

@Deprecated
@Nullable
public Document getDocument(@NonNull String id) {
try { return getDefaultCollectionOrThrow().getDocument(id); }
catch (CouchbaseLiteException e) { throw new IllegalStateException(Log.lookupStandardMessage("DBClosed"), e); }
catch (CouchbaseLiteException e) {
if (e.getCode() == CBLError.Code.NOT_OPEN) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah.... nice. You might have to check the Domain, too...

return null;
catch (CouchbaseLiteException e) {
if (e.getCode() == CBLError.Code.NOT_FOUND) {
Log.i(LogDomain.DATABASE, "Failed retrieving document: %s", id);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think you need to log this. It will happen all the time...

... and, again, might want to check the domain


protected val Scope.collectionCount
get() = this.collections.size

@Before
fun setUpBaseCollectionTest() {
testScope = baseTestDb.defaultScope
testCollection = testScope!!.getCollection(Collection.DEFAULT_NAME)
testColName = "test_collection"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider using the name randomizer: BaseTest.getUniqueName

@@ -1655,14 +1665,38 @@ protected final void verifyDocument(DictionaryInterface doc) {
verifyBlob(doc.getBlob("doc-29"));
}

protected Database openDatabase() throws CouchbaseLiteException { return verifyDb(createDb("test_db")); }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please use the name randomizer, here. We've had a a lot of trouble, in the past, with tests failing because of some cruft left around by previous tests.

for (i in 0 until n) {
val doc = MutableDocument(String.format(Locale.US, "doc_%03d", i))
doc.setValue("key", i)
saveDocInBaseCollectionTest(doc)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the "Base" collection the default collection?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, it's the test collection that is created in BaseCollectionTest, but I'll change the name of this function to avoid confusion

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. Cool!

val docID = "doc1"
val doc = MutableDocument(docID)

val coll1 = baseTestDb.createCollection("coll_1")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do worry that many of these tests will fail, if one of them does. We've had that happen a lot in the past. I really do suggest using the name randomizer.


try {
assertNotSame(collection, testCollection)
if (collection != null) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should you assert not null here?


// Update doc and store it into different instance
doc.setValue("key", 2)
TestUtils.assertThrowsCBL(CBLError.Domain.CBLITE, CBLError.Code.INVALID_PARAMETER) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sweet!

Copy link
Contributor

@bmeike bmeike left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add the name randomizer and see what you think of the other comments. Go ahead and commit.

catch (CouchbaseLiteException e) { Log.i(LogDomain.DATABASE, "Failed retrieving document: %s", id); }
return null;
catch (CouchbaseLiteException e) {
if (e.getDomain().equals(CBLError.Domain.CBLITE) && e.getCode() == CBLError.Code.NOT_FOUND) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not requesting a change, here, but FYI:
CBLError.Domain.CBLITE will never be null. That means that saying CBLError.Domain.CBLITE.equals(...) will never NPE.

for (i in 0 until n) {
val doc = MutableDocument(String.format(Locale.US, "doc_%03d", i))
doc.setValue("key", i)
saveDocInBaseCollectionTest(doc)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. Cool!

@@ -55,6 +59,10 @@ public interface DocValidator extends Fn.ConsumerThrows<Document, CouchbaseLiteE

public static C4Database getC4Db(@NonNull Database db) { return db.getOpenC4Database(); }

protected static <T extends Comparable<T>> void assertContents(List<T> l1, T... contents) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh!! Very nice!

deleteDb(db);
throw new AssertionError("Unable to get db path", e);
}
catch (AssertionError e) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ahhh!!!! Gottcha. This isn't a test, its a utility method.
In that case, I don't think it should delete the database at all. It should return true or false and the db creator should be responsible for doing the right thing...

deleteDb(db);
throw new AssertionError("Unable to get db path", e);
}
catch (AssertionError e) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or.... if that would break a lot of legacy code, just rename it "verifyOrDeleteDb"...

@LaurenNguyen14 LaurenNguyen14 merged commit 1da811c into master Jul 12, 2022
@LaurenNguyen14 LaurenNguyen14 deleted the fix/CBL-3341 branch July 12, 2022 17:32
Copy link
Contributor

@bmeike bmeike left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I haven't looked at all of the tests... that, of course, is the important part. Please do walk through them and assure yourself that they are actually testing what they are meant to test.

... and I ask you to do this before, so if you've already done it, just commit. It looks really good.

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