Refactor cache counting into a separate helper class

chrome/browser/browsing_data/cache_counter_browsertest.cc

Index: chrome/browser/browsing_data/cache_counter_browsertest.cc
diff --git a/chrome/browser/browsing_data/cache_counter_browsertest.cc b/chrome/browser/browsing_data/cache_counter_browsertest.cc
index a953f7fb4a0f0cbd1953107c68704e0f9e78c9e9..da7789b9ee3231b65dc5623560afd3a7cd6bdb69 100644
--- a/chrome/browser/browsing_data/cache_counter_browsertest.cc
+++ b/chrome/browser/browsing_data/cache_counter_browsertest.cc
@@ -252,10 +252,7 @@ IN_PROC_BROWSER_TEST_F(CacheCounterTest, PrefIsFalse) {
   EXPECT_FALSE(counter.Pending());
 }
 
-// Tests that the counting is restarted when the time period changes. Currently,
-// the results should be the same for every period. This is because the counter
-// always counts the size of the entire cache, and it is up to the UI
-// to interpret it as exact value or upper bound.
+// Tests that the counting is restarted when the time period changes.

[msramek, 2016/12/15 15:58:50]

Can you add tests for the new behavior?

At minimum, we should test |is_upper_limit|.

Ideally, the test should also be able to inject a smaller time limit and test
the switch from exact computation to the estimate.

[dullweber, 2016/12/16 16:41:10]

I added a test that sets timeout to 0 and checks if is_upper_limit is true. I
also tested that is_upper_limit returns false for the other cases.

 IN_PROC_BROWSER_TEST_F(CacheCounterTest, PeriodChanged) {
   CreateCacheEntry();