mirrors/brew
1
0
Fork 0
mirror of https://github.com/Homebrew/brew.git synced 2025-07-14 16:09:03 +08:00
Code Issues Packages Projects Releases Wiki Activity
brew/Library/Homebrew/test/livecheck/strategy/sparkle_spec.rb

272 lines
9.8 KiB
Ruby
Raw Normal View History

Sparkle: Add test
2020-12-19 01:11:45 -05:00
# typed: false
# frozen_string_literal: true
Standardize valid strategy block return types Valid `strategy` block return types currently vary between strategies. Some only accept a string whereas others accept a string or array of strings. [`strategy` blocks also accept a `nil` return (to simplify early returns) but this was already standardized across strategies.] While some strategies only identify one version by default (where a string is an appropriate return type), it could be that a strategy block identifies more than one version. In this situation, the strategy would need to be modified to accept (and work with) an array from a `strategy` block. Rather than waiting for this to become a problem, this modifies all strategies to standardize on allowing `strategy` blocks to return a string or array of strings (even if only one of these is currently used in practice). Standardizing valid return types helps to further simplify the mental model for `strategy` blocks and reduce cognitive load. This commit extracts related logic from `#find_versions` into methods like `#versions_from_content`, which is conceptually similar to `PageMatch#page_matches` (renamed to `#versions_from_content` for consistency). This allows us to write tests for the related code without having to make network requests (or stub them) at this point. In general, this also helps to better align the structure of strategies and how the various `#find_versions` methods work with versions. There's still more planned work to be done here but this is a step in the right direction.
2021-08-10 11:09:55 -04:00
require "livecheck/strategy"
require "bundle_version"
Sparkle: Add test
2020-12-19 01:11:45 -05:00
describe Homebrew::Livecheck::Strategy::Sparkle do
subject(:sparkle) { described_class }
Improve standardization of strategy tests
2021-08-10 17:39:11 -04:00
let(:appcast_url) { "https://www.example.com/example/appcast.xml" }
let(:non_http_url) { "ftp://brew.sh/" }
Sparkle: Add test
2020-12-19 01:11:45 -05:00
Sparkle: Pass all items into strategy block It's sometimes necessary to work with all the items in a Sparkle feed to be able to correctly identify the newest version but livecheck's `Sparkle` strategy only passes the `item` it views as newest into a `strategy` block. This updates the `Sparkle` strategy to optionally pass all items into a `strategy` block, so we can manipulate them (e.g., filtering, sorting). This is enabled by naming the first argument of the strategy block `items` instead of `item`. `Sparkle` `strategy` blocks where the first argument is `item` will continue to work as expected. This necessarily updates `#item_from_content` (now `items_from_content`) to return all items. I've decided to move the sorting out of `#items_from_content`, so it simply returns the items in the order they appear. If there is ever an exceptional situation where we need the original order, this will technically allow for it. The sorting has instead been moved into the `#versions_from_content` method, to maintain the existing behavior. I thought about passing the items into the `strategy` block in their original order but it feels like sorting by default is the better approach for now (partly from the perspective of maintaining existing behavior) and we can always revisit this in the future if a cask ever requires the original order. Lastly, this expands the `Sparkle` tests to increase coverage. The only untested parts are `#find_versions` (which currently requires a network request) and a couple safeguard `raise` calls when there's a `REXML::UndefinedNamespaceException` (which shouldn't be encountered unless something is broken).
2022-05-31 13:18:40 -04:00
let(:item_hash) {
[
{
title: "Version 1.2.3",
pub_date: "Fri, 01 Jan 2021 01:23:45 +0000",
url: "https://www.example.com/example/example-1.2.3.tar.gz",
short_version: "1.2.3",
version: "123",
},
{
title: "Version 1.2.2",
pub_date: "Not a parseable date string",
url: "https://www.example.com/example/example-1.2.2.tar.gz",
short_version: "1.2.2",
version: "122",
},
]
Sparkle: Expand tests
2020-12-20 01:56:54 -05:00
}
Sparkle: Pass all items into strategy block It's sometimes necessary to work with all the items in a Sparkle feed to be able to correctly identify the newest version but livecheck's `Sparkle` strategy only passes the `item` it views as newest into a `strategy` block. This updates the `Sparkle` strategy to optionally pass all items into a `strategy` block, so we can manipulate them (e.g., filtering, sorting). This is enabled by naming the first argument of the strategy block `items` instead of `item`. `Sparkle` `strategy` blocks where the first argument is `item` will continue to work as expected. This necessarily updates `#item_from_content` (now `items_from_content`) to return all items. I've decided to move the sorting out of `#items_from_content`, so it simply returns the items in the order they appear. If there is ever an exceptional situation where we need the original order, this will technically allow for it. The sorting has instead been moved into the `#versions_from_content` method, to maintain the existing behavior. I thought about passing the items into the `strategy` block in their original order but it feels like sorting by default is the better approach for now (partly from the perspective of maintaining existing behavior) and we can always revisit this in the future if a cask ever requires the original order. Lastly, this expands the `Sparkle` tests to increase coverage. The only untested parts are `#find_versions` (which currently requires a network request) and a couple safeguard `raise` calls when there's a `REXML::UndefinedNamespaceException` (which shouldn't be encountered unless something is broken).
2022-05-31 13:18:40 -04:00
let(:xml) {
first_item = <<~EOS
<item>
<title>#{item_hash[0][:title]}</title>
<sparkle:minimumSystemVersion>10.10</sparkle:minimumSystemVersion>
<sparkle:releaseNotesLink>https://www.example.com/example/#{item_hash[0][:short_version]}.html</sparkle:releaseNotesLink>
<pubDate>#{item_hash[0][:pub_date]}</pubDate>
<enclosure url="#{item_hash[0][:url]}" sparkle:shortVersionString="#{item_hash[0][:short_version]}" sparkle:version="#{item_hash[0][:version]}" length="12345678" type="application/octet-stream" sparkle:dsaSignature="ABCDEF+GHIJKLMNOPQRSTUVWXYZab/cdefghijklmnopqrst/uvwxyz1234567==" />
</item>
EOS
second_item = <<~EOS
<item>
<title>#{item_hash[1][:title]}</title>
<sparkle:minimumSystemVersion>10.10</sparkle:minimumSystemVersion>
<sparkle:releaseNotesLink>https://www.example.com/example/#{item_hash[1][:short_version]}.html</sparkle:releaseNotesLink>
<pubDate>#{item_hash[1][:pub_date]}</pubDate>
<sparkle:version>#{item_hash[1][:version]}</sparkle:version>
<sparkle:shortVersionString>#{item_hash[1][:short_version]}</sparkle:shortVersionString>
<link>#{item_hash[1][:url]}</link>
</item>
EOS
appcast_xml = <<~EOS
Sparkle: Expand tests
2020-12-20 01:56:54 -05:00
<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:sparkle="http://www.andymatuschak.org/xml-namespaces/sparkle">
<channel>
<title>Example Changelog</title>
Improve standardization of strategy tests
2021-08-10 17:39:11 -04:00
<link>#{appcast_url}</link>
Sparkle: Expand tests
2020-12-20 01:56:54 -05:00
<description>Most recent changes with links to updates.</description>
<language>en</language>
Sparkle: Pass all items into strategy block It's sometimes necessary to work with all the items in a Sparkle feed to be able to correctly identify the newest version but livecheck's `Sparkle` strategy only passes the `item` it views as newest into a `strategy` block. This updates the `Sparkle` strategy to optionally pass all items into a `strategy` block, so we can manipulate them (e.g., filtering, sorting). This is enabled by naming the first argument of the strategy block `items` instead of `item`. `Sparkle` `strategy` blocks where the first argument is `item` will continue to work as expected. This necessarily updates `#item_from_content` (now `items_from_content`) to return all items. I've decided to move the sorting out of `#items_from_content`, so it simply returns the items in the order they appear. If there is ever an exceptional situation where we need the original order, this will technically allow for it. The sorting has instead been moved into the `#versions_from_content` method, to maintain the existing behavior. I thought about passing the items into the `strategy` block in their original order but it feels like sorting by default is the better approach for now (partly from the perspective of maintaining existing behavior) and we can always revisit this in the future if a cask ever requires the original order. Lastly, this expands the `Sparkle` tests to increase coverage. The only untested parts are `#find_versions` (which currently requires a network request) and a couple safeguard `raise` calls when there's a `REXML::UndefinedNamespaceException` (which shouldn't be encountered unless something is broken).
2022-05-31 13:18:40 -04:00
#{first_item}
#{second_item}
Sparkle: Expand tests
2020-12-20 01:56:54 -05:00
</channel>
</rss>
EOS
Sparkle: Pass all items into strategy block It's sometimes necessary to work with all the items in a Sparkle feed to be able to correctly identify the newest version but livecheck's `Sparkle` strategy only passes the `item` it views as newest into a `strategy` block. This updates the `Sparkle` strategy to optionally pass all items into a `strategy` block, so we can manipulate them (e.g., filtering, sorting). This is enabled by naming the first argument of the strategy block `items` instead of `item`. `Sparkle` `strategy` blocks where the first argument is `item` will continue to work as expected. This necessarily updates `#item_from_content` (now `items_from_content`) to return all items. I've decided to move the sorting out of `#items_from_content`, so it simply returns the items in the order they appear. If there is ever an exceptional situation where we need the original order, this will technically allow for it. The sorting has instead been moved into the `#versions_from_content` method, to maintain the existing behavior. I thought about passing the items into the `strategy` block in their original order but it feels like sorting by default is the better approach for now (partly from the perspective of maintaining existing behavior) and we can always revisit this in the future if a cask ever requires the original order. Lastly, this expands the `Sparkle` tests to increase coverage. The only untested parts are `#find_versions` (which currently requires a network request) and a couple safeguard `raise` calls when there's a `REXML::UndefinedNamespaceException` (which shouldn't be encountered unless something is broken).
2022-05-31 13:18:40 -04:00
extra_items = <<~EOS
#{first_item.sub(%r{<(enclosure[^>]+?)\s*?/>}, '<\1 os="not-osx" />')}
#{first_item.sub(/(<sparkle:minimumSystemVersion>)[^<]+?</m, '\1100<')}
#{first_item.sub(/(<sparkle:minimumSystemVersion>)[^<]+?</m, '\19000<')}
<item>
</item>
EOS
appcast_with_omitted_items = appcast_xml.sub("</item>", "</item>\n#{extra_items}")
Sparkle: Provide channel information in Item Making `channel` information available in the `Item` is necessary to be able to filter out unstable items using a `strategy` block. If an item doesn't specify a channel, then it uses the default channel (this is what Sparkle itself uses for updates). Channels like `beta` are something we want to avoid for stable casks and this allows for that type of [cask-specific] filtering. It's technically possible to automatically filter out items that aren't using the default channel (i.e., `channel != nil`) in `#items_from_content` but some casks use an unstable version, so we can't do this internally. That is to say, we wouldn't be able to override internal filtering in a `strategy` block, as any omitted items wouldn't be provided to the block. Conversely, if we pass all items to a `strategy` block, we can easily filter by channel there. We haven't been filtering by channel internally and we've only found one cask where this has been a problem, so it seems fine for now.
2022-06-02 10:04:34 -04:00
beta_channel_item = appcast_xml.sub(
first_item,
first_item.sub(
"</title",
"</title>\n<sparkle:channel>beta</sparkle:channel>",
),
)
Sparkle: Pass all items into strategy block It's sometimes necessary to work with all the items in a Sparkle feed to be able to correctly identify the newest version but livecheck's `Sparkle` strategy only passes the `item` it views as newest into a `strategy` block. This updates the `Sparkle` strategy to optionally pass all items into a `strategy` block, so we can manipulate them (e.g., filtering, sorting). This is enabled by naming the first argument of the strategy block `items` instead of `item`. `Sparkle` `strategy` blocks where the first argument is `item` will continue to work as expected. This necessarily updates `#item_from_content` (now `items_from_content`) to return all items. I've decided to move the sorting out of `#items_from_content`, so it simply returns the items in the order they appear. If there is ever an exceptional situation where we need the original order, this will technically allow for it. The sorting has instead been moved into the `#versions_from_content` method, to maintain the existing behavior. I thought about passing the items into the `strategy` block in their original order but it feels like sorting by default is the better approach for now (partly from the perspective of maintaining existing behavior) and we can always revisit this in the future if a cask ever requires the original order. Lastly, this expands the `Sparkle` tests to increase coverage. The only untested parts are `#find_versions` (which currently requires a network request) and a couple safeguard `raise` calls when there's a `REXML::UndefinedNamespaceException` (which shouldn't be encountered unless something is broken).
2022-05-31 13:18:40 -04:00
no_versions_item =
appcast_xml
.sub(second_item, "")
.gsub(/sparkle:(shortVersionString|version)="[^"]+?"\s*/, "")
.sub(
"<title>#{item_hash[0][:title]}</title>",
"<title>Version</title>",
)
no_items = appcast_xml.sub(%r{<item>.+</item>}m, "")
undefined_namespace_xml = appcast_xml.sub(/\s*xmlns:sparkle="[^"]+?"/, "")
{
appcast: appcast_xml,
appcast_with_omitted_items: appcast_with_omitted_items,
Sparkle: Provide channel information in Item Making `channel` information available in the `Item` is necessary to be able to filter out unstable items using a `strategy` block. If an item doesn't specify a channel, then it uses the default channel (this is what Sparkle itself uses for updates). Channels like `beta` are something we want to avoid for stable casks and this allows for that type of [cask-specific] filtering. It's technically possible to automatically filter out items that aren't using the default channel (i.e., `channel != nil`) in `#items_from_content` but some casks use an unstable version, so we can't do this internally. That is to say, we wouldn't be able to override internal filtering in a `strategy` block, as any omitted items wouldn't be provided to the block. Conversely, if we pass all items to a `strategy` block, we can easily filter by channel there. We haven't been filtering by channel internally and we've only found one cask where this has been a problem, so it seems fine for now.
2022-06-02 10:04:34 -04:00
beta_channel_item: beta_channel_item,
Sparkle: Pass all items into strategy block It's sometimes necessary to work with all the items in a Sparkle feed to be able to correctly identify the newest version but livecheck's `Sparkle` strategy only passes the `item` it views as newest into a `strategy` block. This updates the `Sparkle` strategy to optionally pass all items into a `strategy` block, so we can manipulate them (e.g., filtering, sorting). This is enabled by naming the first argument of the strategy block `items` instead of `item`. `Sparkle` `strategy` blocks where the first argument is `item` will continue to work as expected. This necessarily updates `#item_from_content` (now `items_from_content`) to return all items. I've decided to move the sorting out of `#items_from_content`, so it simply returns the items in the order they appear. If there is ever an exceptional situation where we need the original order, this will technically allow for it. The sorting has instead been moved into the `#versions_from_content` method, to maintain the existing behavior. I thought about passing the items into the `strategy` block in their original order but it feels like sorting by default is the better approach for now (partly from the perspective of maintaining existing behavior) and we can always revisit this in the future if a cask ever requires the original order. Lastly, this expands the `Sparkle` tests to increase coverage. The only untested parts are `#find_versions` (which currently requires a network request) and a couple safeguard `raise` calls when there's a `REXML::UndefinedNamespaceException` (which shouldn't be encountered unless something is broken).
2022-05-31 13:18:40 -04:00
no_versions_item: no_versions_item,
no_items: no_items,
undefined_namespace: undefined_namespace_xml,
}
Sparkle: Expand tests
2020-12-20 01:56:54 -05:00
}
Allow regex to be passed into all strategy blocks This modifies cask-related livecheck strategies to allow passing a regex into a `strategy` block, when appropriate. These strategies were outliers that explicitly rejected a regex even if a `strategy` block was used, forcing any regex to be inlined in the `strategy` block (instead of being defined using `#regex`). With these changes, all `strategy` blocks will be able to accept a regex, further simplifying the mental model. This also helps to better align the various `find_versions` and `versions_from_*` methods across strategies.
2021-11-16 12:31:54 -05:00
let(:title_regex) { /Version\s+v?(\d+(?:\.\d+)+)\s*$/i }
Sparkle: Pass all items into strategy block It's sometimes necessary to work with all the items in a Sparkle feed to be able to correctly identify the newest version but livecheck's `Sparkle` strategy only passes the `item` it views as newest into a `strategy` block. This updates the `Sparkle` strategy to optionally pass all items into a `strategy` block, so we can manipulate them (e.g., filtering, sorting). This is enabled by naming the first argument of the strategy block `items` instead of `item`. `Sparkle` `strategy` blocks where the first argument is `item` will continue to work as expected. This necessarily updates `#item_from_content` (now `items_from_content`) to return all items. I've decided to move the sorting out of `#items_from_content`, so it simply returns the items in the order they appear. If there is ever an exceptional situation where we need the original order, this will technically allow for it. The sorting has instead been moved into the `#versions_from_content` method, to maintain the existing behavior. I thought about passing the items into the `strategy` block in their original order but it feels like sorting by default is the better approach for now (partly from the perspective of maintaining existing behavior) and we can always revisit this in the future if a cask ever requires the original order. Lastly, this expands the `Sparkle` tests to increase coverage. The only untested parts are `#find_versions` (which currently requires a network request) and a couple safeguard `raise` calls when there's a `REXML::UndefinedNamespaceException` (which shouldn't be encountered unless something is broken).
2022-05-31 13:18:40 -04:00
let(:items) {
Sparkle: Provide channel information in Item Making `channel` information available in the `Item` is necessary to be able to filter out unstable items using a `strategy` block. If an item doesn't specify a channel, then it uses the default channel (this is what Sparkle itself uses for updates). Channels like `beta` are something we want to avoid for stable casks and this allows for that type of [cask-specific] filtering. It's technically possible to automatically filter out items that aren't using the default channel (i.e., `channel != nil`) in `#items_from_content` but some casks use an unstable version, so we can't do this internally. That is to say, we wouldn't be able to override internal filtering in a `strategy` block, as any omitted items wouldn't be provided to the block. Conversely, if we pass all items to a `strategy` block, we can easily filter by channel there. We haven't been filtering by channel internally and we've only found one cask where this has been a problem, so it seems fine for now.
2022-06-02 10:04:34 -04:00
items = {
Sparkle: Pass all items into strategy block It's sometimes necessary to work with all the items in a Sparkle feed to be able to correctly identify the newest version but livecheck's `Sparkle` strategy only passes the `item` it views as newest into a `strategy` block. This updates the `Sparkle` strategy to optionally pass all items into a `strategy` block, so we can manipulate them (e.g., filtering, sorting). This is enabled by naming the first argument of the strategy block `items` instead of `item`. `Sparkle` `strategy` blocks where the first argument is `item` will continue to work as expected. This necessarily updates `#item_from_content` (now `items_from_content`) to return all items. I've decided to move the sorting out of `#items_from_content`, so it simply returns the items in the order they appear. If there is ever an exceptional situation where we need the original order, this will technically allow for it. The sorting has instead been moved into the `#versions_from_content` method, to maintain the existing behavior. I thought about passing the items into the `strategy` block in their original order but it feels like sorting by default is the better approach for now (partly from the perspective of maintaining existing behavior) and we can always revisit this in the future if a cask ever requires the original order. Lastly, this expands the `Sparkle` tests to increase coverage. The only untested parts are `#find_versions` (which currently requires a network request) and a couple safeguard `raise` calls when there's a `REXML::UndefinedNamespaceException` (which shouldn't be encountered unless something is broken).
2022-05-31 13:18:40 -04:00
appcast: [
Homebrew::Livecheck::Strategy::Sparkle::Item.new(
title: item_hash[0][:title],
pub_date: Time.parse(item_hash[0][:pub_date]),
url: item_hash[0][:url],
bundle_version: Homebrew::BundleVersion.new(item_hash[0][:short_version], item_hash[0][:version]),
),
Homebrew::Livecheck::Strategy::Sparkle::Item.new(
title: item_hash[1][:title],
pub_date: Time.new(0),
url: item_hash[1][:url],
bundle_version: Homebrew::BundleVersion.new(item_hash[1][:short_version], item_hash[1][:version]),
),
],
no_versions_item: [
Homebrew::Livecheck::Strategy::Sparkle::Item.new(
title: "Version",
pub_date: Time.parse(item_hash[0][:pub_date]),
url: item_hash[0][:url],
bundle_version: nil,
),
],
}
Sparkle: Provide channel information in Item Making `channel` information available in the `Item` is necessary to be able to filter out unstable items using a `strategy` block. If an item doesn't specify a channel, then it uses the default channel (this is what Sparkle itself uses for updates). Channels like `beta` are something we want to avoid for stable casks and this allows for that type of [cask-specific] filtering. It's technically possible to automatically filter out items that aren't using the default channel (i.e., `channel != nil`) in `#items_from_content` but some casks use an unstable version, so we can't do this internally. That is to say, we wouldn't be able to override internal filtering in a `strategy` block, as any omitted items wouldn't be provided to the block. Conversely, if we pass all items to a `strategy` block, we can easily filter by channel there. We haven't been filtering by channel internally and we've only found one cask where this has been a problem, so it seems fine for now.
2022-06-02 10:04:34 -04:00
beta_channel_item = items[:appcast][0].clone
beta_channel_item.channel = "beta"
items[:beta_channel_item] = [beta_channel_item, items[:appcast][1].clone]
items
Standardize valid strategy block return types Valid `strategy` block return types currently vary between strategies. Some only accept a string whereas others accept a string or array of strings. [`strategy` blocks also accept a `nil` return (to simplify early returns) but this was already standardized across strategies.] While some strategies only identify one version by default (where a string is an appropriate return type), it could be that a strategy block identifies more than one version. In this situation, the strategy would need to be modified to accept (and work with) an array from a `strategy` block. Rather than waiting for this to become a problem, this modifies all strategies to standardize on allowing `strategy` blocks to return a string or array of strings (even if only one of these is currently used in practice). Standardizing valid return types helps to further simplify the mental model for `strategy` blocks and reduce cognitive load. This commit extracts related logic from `#find_versions` into methods like `#versions_from_content`, which is conceptually similar to `PageMatch#page_matches` (renamed to `#versions_from_content` for consistency). This allows us to write tests for the related code without having to make network requests (or stub them) at this point. In general, this also helps to better align the structure of strategies and how the various `#find_versions` methods work with versions. There's still more planned work to be done here but this is a step in the right direction.
2021-08-10 11:09:55 -04:00
}
Sparkle: Pass all items into strategy block It's sometimes necessary to work with all the items in a Sparkle feed to be able to correctly identify the newest version but livecheck's `Sparkle` strategy only passes the `item` it views as newest into a `strategy` block. This updates the `Sparkle` strategy to optionally pass all items into a `strategy` block, so we can manipulate them (e.g., filtering, sorting). This is enabled by naming the first argument of the strategy block `items` instead of `item`. `Sparkle` `strategy` blocks where the first argument is `item` will continue to work as expected. This necessarily updates `#item_from_content` (now `items_from_content`) to return all items. I've decided to move the sorting out of `#items_from_content`, so it simply returns the items in the order they appear. If there is ever an exceptional situation where we need the original order, this will technically allow for it. The sorting has instead been moved into the `#versions_from_content` method, to maintain the existing behavior. I thought about passing the items into the `strategy` block in their original order but it feels like sorting by default is the better approach for now (partly from the perspective of maintaining existing behavior) and we can always revisit this in the future if a cask ever requires the original order. Lastly, this expands the `Sparkle` tests to increase coverage. The only untested parts are `#find_versions` (which currently requires a network request) and a couple safeguard `raise` calls when there's a `REXML::UndefinedNamespaceException` (which shouldn't be encountered unless something is broken).
2022-05-31 13:18:40 -04:00
let(:versions) { [items[:appcast][0].nice_version] }
Standardize valid strategy block return types Valid `strategy` block return types currently vary between strategies. Some only accept a string whereas others accept a string or array of strings. [`strategy` blocks also accept a `nil` return (to simplify early returns) but this was already standardized across strategies.] While some strategies only identify one version by default (where a string is an appropriate return type), it could be that a strategy block identifies more than one version. In this situation, the strategy would need to be modified to accept (and work with) an array from a `strategy` block. Rather than waiting for this to become a problem, this modifies all strategies to standardize on allowing `strategy` blocks to return a string or array of strings (even if only one of these is currently used in practice). Standardizing valid return types helps to further simplify the mental model for `strategy` blocks and reduce cognitive load. This commit extracts related logic from `#find_versions` into methods like `#versions_from_content`, which is conceptually similar to `PageMatch#page_matches` (renamed to `#versions_from_content` for consistency). This allows us to write tests for the related code without having to make network requests (or stub them) at this point. In general, this also helps to better align the structure of strategies and how the various `#find_versions` methods work with versions. There's still more planned work to be done here but this is a step in the right direction.
2021-08-10 11:09:55 -04:00
Sparkle: Add test
2020-12-19 01:11:45 -05:00
describe "::match?" do
Improve standardization of strategy tests
2021-08-10 17:39:11 -04:00
it "returns true for an HTTP URL" do
expect(sparkle.match?(appcast_url)).to be true
end
it "returns false for a non-HTTP URL" do
expect(sparkle.match?(non_http_url)).to be false
Sparkle: Add test
2020-12-19 01:11:45 -05:00
end
end
Sparkle: Expand tests
2020-12-20 01:56:54 -05:00
Sparkle: Pass all items into strategy block It's sometimes necessary to work with all the items in a Sparkle feed to be able to correctly identify the newest version but livecheck's `Sparkle` strategy only passes the `item` it views as newest into a `strategy` block. This updates the `Sparkle` strategy to optionally pass all items into a `strategy` block, so we can manipulate them (e.g., filtering, sorting). This is enabled by naming the first argument of the strategy block `items` instead of `item`. `Sparkle` `strategy` blocks where the first argument is `item` will continue to work as expected. This necessarily updates `#item_from_content` (now `items_from_content`) to return all items. I've decided to move the sorting out of `#items_from_content`, so it simply returns the items in the order they appear. If there is ever an exceptional situation where we need the original order, this will technically allow for it. The sorting has instead been moved into the `#versions_from_content` method, to maintain the existing behavior. I thought about passing the items into the `strategy` block in their original order but it feels like sorting by default is the better approach for now (partly from the perspective of maintaining existing behavior) and we can always revisit this in the future if a cask ever requires the original order. Lastly, this expands the `Sparkle` tests to increase coverage. The only untested parts are `#find_versions` (which currently requires a network request) and a couple safeguard `raise` calls when there's a `REXML::UndefinedNamespaceException` (which shouldn't be encountered unless something is broken).
2022-05-31 13:18:40 -04:00
describe "::items_from_content" do
let(:items_from_appcast_xml) { sparkle.items_from_content(xml[:appcast]) }
let(:first_item) { items_from_appcast_xml[0] }
Sparkle: Expand tests
2020-12-20 01:56:54 -05:00
it "returns nil if content is blank" do
Sparkle: Pass all items into strategy block It's sometimes necessary to work with all the items in a Sparkle feed to be able to correctly identify the newest version but livecheck's `Sparkle` strategy only passes the `item` it views as newest into a `strategy` block. This updates the `Sparkle` strategy to optionally pass all items into a `strategy` block, so we can manipulate them (e.g., filtering, sorting). This is enabled by naming the first argument of the strategy block `items` instead of `item`. `Sparkle` `strategy` blocks where the first argument is `item` will continue to work as expected. This necessarily updates `#item_from_content` (now `items_from_content`) to return all items. I've decided to move the sorting out of `#items_from_content`, so it simply returns the items in the order they appear. If there is ever an exceptional situation where we need the original order, this will technically allow for it. The sorting has instead been moved into the `#versions_from_content` method, to maintain the existing behavior. I thought about passing the items into the `strategy` block in their original order but it feels like sorting by default is the better approach for now (partly from the perspective of maintaining existing behavior) and we can always revisit this in the future if a cask ever requires the original order. Lastly, this expands the `Sparkle` tests to increase coverage. The only untested parts are `#find_versions` (which currently requires a network request) and a couple safeguard `raise` calls when there's a `REXML::UndefinedNamespaceException` (which shouldn't be encountered unless something is broken).
2022-05-31 13:18:40 -04:00
expect(sparkle.items_from_content("")).to eq([])
Sparkle: Expand tests
2020-12-20 01:56:54 -05:00
end
Sparkle: Pass all items into strategy block It's sometimes necessary to work with all the items in a Sparkle feed to be able to correctly identify the newest version but livecheck's `Sparkle` strategy only passes the `item` it views as newest into a `strategy` block. This updates the `Sparkle` strategy to optionally pass all items into a `strategy` block, so we can manipulate them (e.g., filtering, sorting). This is enabled by naming the first argument of the strategy block `items` instead of `item`. `Sparkle` `strategy` blocks where the first argument is `item` will continue to work as expected. This necessarily updates `#item_from_content` (now `items_from_content`) to return all items. I've decided to move the sorting out of `#items_from_content`, so it simply returns the items in the order they appear. If there is ever an exceptional situation where we need the original order, this will technically allow for it. The sorting has instead been moved into the `#versions_from_content` method, to maintain the existing behavior. I thought about passing the items into the `strategy` block in their original order but it feels like sorting by default is the better approach for now (partly from the perspective of maintaining existing behavior) and we can always revisit this in the future if a cask ever requires the original order. Lastly, this expands the `Sparkle` tests to increase coverage. The only untested parts are `#find_versions` (which currently requires a network request) and a couple safeguard `raise` calls when there's a `REXML::UndefinedNamespaceException` (which shouldn't be encountered unless something is broken).
2022-05-31 13:18:40 -04:00
it "returns an array of Items when given XML data" do
expect(items_from_appcast_xml).to eq(items[:appcast])
expect(first_item.title).to eq(item_hash[0][:title])
expect(first_item.pub_date).to eq(Time.parse(item_hash[0][:pub_date]))
expect(first_item.url).to eq(item_hash[0][:url])
expect(first_item.short_version).to eq(item_hash[0][:short_version])
expect(first_item.version).to eq(item_hash[0][:version])
Sparkle: Provide channel information in Item Making `channel` information available in the `Item` is necessary to be able to filter out unstable items using a `strategy` block. If an item doesn't specify a channel, then it uses the default channel (this is what Sparkle itself uses for updates). Channels like `beta` are something we want to avoid for stable casks and this allows for that type of [cask-specific] filtering. It's technically possible to automatically filter out items that aren't using the default channel (i.e., `channel != nil`) in `#items_from_content` but some casks use an unstable version, so we can't do this internally. That is to say, we wouldn't be able to override internal filtering in a `strategy` block, as any omitted items wouldn't be provided to the block. Conversely, if we pass all items to a `strategy` block, we can easily filter by channel there. We haven't been filtering by channel internally and we've only found one cask where this has been a problem, so it seems fine for now.
2022-06-02 10:04:34 -04:00
expect(sparkle.items_from_content(xml[:beta_channel_item])).to eq(items[:beta_channel_item])
Sparkle: Pass all items into strategy block It's sometimes necessary to work with all the items in a Sparkle feed to be able to correctly identify the newest version but livecheck's `Sparkle` strategy only passes the `item` it views as newest into a `strategy` block. This updates the `Sparkle` strategy to optionally pass all items into a `strategy` block, so we can manipulate them (e.g., filtering, sorting). This is enabled by naming the first argument of the strategy block `items` instead of `item`. `Sparkle` `strategy` blocks where the first argument is `item` will continue to work as expected. This necessarily updates `#item_from_content` (now `items_from_content`) to return all items. I've decided to move the sorting out of `#items_from_content`, so it simply returns the items in the order they appear. If there is ever an exceptional situation where we need the original order, this will technically allow for it. The sorting has instead been moved into the `#versions_from_content` method, to maintain the existing behavior. I thought about passing the items into the `strategy` block in their original order but it feels like sorting by default is the better approach for now (partly from the perspective of maintaining existing behavior) and we can always revisit this in the future if a cask ever requires the original order. Lastly, this expands the `Sparkle` tests to increase coverage. The only untested parts are `#find_versions` (which currently requires a network request) and a couple safeguard `raise` calls when there's a `REXML::UndefinedNamespaceException` (which shouldn't be encountered unless something is broken).
2022-05-31 13:18:40 -04:00
expect(sparkle.items_from_content(xml[:no_versions_item])).to eq(items[:no_versions_item])
Sparkle: Expand tests
2020-12-20 01:56:54 -05:00
end
end
Standardize valid strategy block return types Valid `strategy` block return types currently vary between strategies. Some only accept a string whereas others accept a string or array of strings. [`strategy` blocks also accept a `nil` return (to simplify early returns) but this was already standardized across strategies.] While some strategies only identify one version by default (where a string is an appropriate return type), it could be that a strategy block identifies more than one version. In this situation, the strategy would need to be modified to accept (and work with) an array from a `strategy` block. Rather than waiting for this to become a problem, this modifies all strategies to standardize on allowing `strategy` blocks to return a string or array of strings (even if only one of these is currently used in practice). Standardizing valid return types helps to further simplify the mental model for `strategy` blocks and reduce cognitive load. This commit extracts related logic from `#find_versions` into methods like `#versions_from_content`, which is conceptually similar to `PageMatch#page_matches` (renamed to `#versions_from_content` for consistency). This allows us to write tests for the related code without having to make network requests (or stub them) at this point. In general, this also helps to better align the structure of strategies and how the various `#find_versions` methods work with versions. There's still more planned work to be done here but this is a step in the right direction.
2021-08-10 11:09:55 -04:00
describe "::versions_from_content" do
Sparkle: Pass all items into strategy block It's sometimes necessary to work with all the items in a Sparkle feed to be able to correctly identify the newest version but livecheck's `Sparkle` strategy only passes the `item` it views as newest into a `strategy` block. This updates the `Sparkle` strategy to optionally pass all items into a `strategy` block, so we can manipulate them (e.g., filtering, sorting). This is enabled by naming the first argument of the strategy block `items` instead of `item`. `Sparkle` `strategy` blocks where the first argument is `item` will continue to work as expected. This necessarily updates `#item_from_content` (now `items_from_content`) to return all items. I've decided to move the sorting out of `#items_from_content`, so it simply returns the items in the order they appear. If there is ever an exceptional situation where we need the original order, this will technically allow for it. The sorting has instead been moved into the `#versions_from_content` method, to maintain the existing behavior. I thought about passing the items into the `strategy` block in their original order but it feels like sorting by default is the better approach for now (partly from the perspective of maintaining existing behavior) and we can always revisit this in the future if a cask ever requires the original order. Lastly, this expands the `Sparkle` tests to increase coverage. The only untested parts are `#find_versions` (which currently requires a network request) and a couple safeguard `raise` calls when there's a `REXML::UndefinedNamespaceException` (which shouldn't be encountered unless something is broken).
2022-05-31 13:18:40 -04:00
let(:subbed_items) { items[:appcast].map { |item| item.nice_version.sub("1", "0") } }
Standardize valid strategy block return types Valid `strategy` block return types currently vary between strategies. Some only accept a string whereas others accept a string or array of strings. [`strategy` blocks also accept a `nil` return (to simplify early returns) but this was already standardized across strategies.] While some strategies only identify one version by default (where a string is an appropriate return type), it could be that a strategy block identifies more than one version. In this situation, the strategy would need to be modified to accept (and work with) an array from a `strategy` block. Rather than waiting for this to become a problem, this modifies all strategies to standardize on allowing `strategy` blocks to return a string or array of strings (even if only one of these is currently used in practice). Standardizing valid return types helps to further simplify the mental model for `strategy` blocks and reduce cognitive load. This commit extracts related logic from `#find_versions` into methods like `#versions_from_content`, which is conceptually similar to `PageMatch#page_matches` (renamed to `#versions_from_content` for consistency). This allows us to write tests for the related code without having to make network requests (or stub them) at this point. In general, this also helps to better align the structure of strategies and how the various `#find_versions` methods work with versions. There's still more planned work to be done here but this is a step in the right direction.
2021-08-10 11:09:55 -04:00
it "returns an array of version strings when given content" do
Sparkle: Pass all items into strategy block It's sometimes necessary to work with all the items in a Sparkle feed to be able to correctly identify the newest version but livecheck's `Sparkle` strategy only passes the `item` it views as newest into a `strategy` block. This updates the `Sparkle` strategy to optionally pass all items into a `strategy` block, so we can manipulate them (e.g., filtering, sorting). This is enabled by naming the first argument of the strategy block `items` instead of `item`. `Sparkle` `strategy` blocks where the first argument is `item` will continue to work as expected. This necessarily updates `#item_from_content` (now `items_from_content`) to return all items. I've decided to move the sorting out of `#items_from_content`, so it simply returns the items in the order they appear. If there is ever an exceptional situation where we need the original order, this will technically allow for it. The sorting has instead been moved into the `#versions_from_content` method, to maintain the existing behavior. I thought about passing the items into the `strategy` block in their original order but it feels like sorting by default is the better approach for now (partly from the perspective of maintaining existing behavior) and we can always revisit this in the future if a cask ever requires the original order. Lastly, this expands the `Sparkle` tests to increase coverage. The only untested parts are `#find_versions` (which currently requires a network request) and a couple safeguard `raise` calls when there's a `REXML::UndefinedNamespaceException` (which shouldn't be encountered unless something is broken).
2022-05-31 13:18:40 -04:00
expect(sparkle.versions_from_content(xml[:appcast])).to eq(versions)
expect(sparkle.versions_from_content(xml[:appcast_with_omitted_items])).to eq(versions)
Sparkle: Provide channel information in Item Making `channel` information available in the `Item` is necessary to be able to filter out unstable items using a `strategy` block. If an item doesn't specify a channel, then it uses the default channel (this is what Sparkle itself uses for updates). Channels like `beta` are something we want to avoid for stable casks and this allows for that type of [cask-specific] filtering. It's technically possible to automatically filter out items that aren't using the default channel (i.e., `channel != nil`) in `#items_from_content` but some casks use an unstable version, so we can't do this internally. That is to say, we wouldn't be able to override internal filtering in a `strategy` block, as any omitted items wouldn't be provided to the block. Conversely, if we pass all items to a `strategy` block, we can easily filter by channel there. We haven't been filtering by channel internally and we've only found one cask where this has been a problem, so it seems fine for now.
2022-06-02 10:04:34 -04:00
expect(sparkle.versions_from_content(xml[:beta_channel_item])).to eq(versions)
Sparkle: Pass all items into strategy block It's sometimes necessary to work with all the items in a Sparkle feed to be able to correctly identify the newest version but livecheck's `Sparkle` strategy only passes the `item` it views as newest into a `strategy` block. This updates the `Sparkle` strategy to optionally pass all items into a `strategy` block, so we can manipulate them (e.g., filtering, sorting). This is enabled by naming the first argument of the strategy block `items` instead of `item`. `Sparkle` `strategy` blocks where the first argument is `item` will continue to work as expected. This necessarily updates `#item_from_content` (now `items_from_content`) to return all items. I've decided to move the sorting out of `#items_from_content`, so it simply returns the items in the order they appear. If there is ever an exceptional situation where we need the original order, this will technically allow for it. The sorting has instead been moved into the `#versions_from_content` method, to maintain the existing behavior. I thought about passing the items into the `strategy` block in their original order but it feels like sorting by default is the better approach for now (partly from the perspective of maintaining existing behavior) and we can always revisit this in the future if a cask ever requires the original order. Lastly, this expands the `Sparkle` tests to increase coverage. The only untested parts are `#find_versions` (which currently requires a network request) and a couple safeguard `raise` calls when there's a `REXML::UndefinedNamespaceException` (which shouldn't be encountered unless something is broken).
2022-05-31 13:18:40 -04:00
expect(sparkle.versions_from_content(xml[:no_versions_item])).to eq([])
expect(sparkle.versions_from_content(xml[:undefined_namespace])).to eq(versions)
end
it "returns an empty array if no items are found" do
expect(sparkle.versions_from_content(xml[:no_items])).to eq([])
Standardize valid strategy block return types Valid `strategy` block return types currently vary between strategies. Some only accept a string whereas others accept a string or array of strings. [`strategy` blocks also accept a `nil` return (to simplify early returns) but this was already standardized across strategies.] While some strategies only identify one version by default (where a string is an appropriate return type), it could be that a strategy block identifies more than one version. In this situation, the strategy would need to be modified to accept (and work with) an array from a `strategy` block. Rather than waiting for this to become a problem, this modifies all strategies to standardize on allowing `strategy` blocks to return a string or array of strings (even if only one of these is currently used in practice). Standardizing valid return types helps to further simplify the mental model for `strategy` blocks and reduce cognitive load. This commit extracts related logic from `#find_versions` into methods like `#versions_from_content`, which is conceptually similar to `PageMatch#page_matches` (renamed to `#versions_from_content` for consistency). This allows us to write tests for the related code without having to make network requests (or stub them) at this point. In general, this also helps to better align the structure of strategies and how the various `#find_versions` methods work with versions. There's still more planned work to be done here but this is a step in the right direction.
2021-08-10 11:09:55 -04:00
end
it "returns an array of version strings when given content and a block" do
# Returning a string from block
expect(
Sparkle: Pass all items into strategy block It's sometimes necessary to work with all the items in a Sparkle feed to be able to correctly identify the newest version but livecheck's `Sparkle` strategy only passes the `item` it views as newest into a `strategy` block. This updates the `Sparkle` strategy to optionally pass all items into a `strategy` block, so we can manipulate them (e.g., filtering, sorting). This is enabled by naming the first argument of the strategy block `items` instead of `item`. `Sparkle` `strategy` blocks where the first argument is `item` will continue to work as expected. This necessarily updates `#item_from_content` (now `items_from_content`) to return all items. I've decided to move the sorting out of `#items_from_content`, so it simply returns the items in the order they appear. If there is ever an exceptional situation where we need the original order, this will technically allow for it. The sorting has instead been moved into the `#versions_from_content` method, to maintain the existing behavior. I thought about passing the items into the `strategy` block in their original order but it feels like sorting by default is the better approach for now (partly from the perspective of maintaining existing behavior) and we can always revisit this in the future if a cask ever requires the original order. Lastly, this expands the `Sparkle` tests to increase coverage. The only untested parts are `#find_versions` (which currently requires a network request) and a couple safeguard `raise` calls when there's a `REXML::UndefinedNamespaceException` (which shouldn't be encountered unless something is broken).
2022-05-31 13:18:40 -04:00
sparkle.versions_from_content(xml[:appcast]) do |item|
item.nice_version&.sub("1", "0")
Standardize valid strategy block return types Valid `strategy` block return types currently vary between strategies. Some only accept a string whereas others accept a string or array of strings. [`strategy` blocks also accept a `nil` return (to simplify early returns) but this was already standardized across strategies.] While some strategies only identify one version by default (where a string is an appropriate return type), it could be that a strategy block identifies more than one version. In this situation, the strategy would need to be modified to accept (and work with) an array from a `strategy` block. Rather than waiting for this to become a problem, this modifies all strategies to standardize on allowing `strategy` blocks to return a string or array of strings (even if only one of these is currently used in practice). Standardizing valid return types helps to further simplify the mental model for `strategy` blocks and reduce cognitive load. This commit extracts related logic from `#find_versions` into methods like `#versions_from_content`, which is conceptually similar to `PageMatch#page_matches` (renamed to `#versions_from_content` for consistency). This allows us to write tests for the related code without having to make network requests (or stub them) at this point. In general, this also helps to better align the structure of strategies and how the various `#find_versions` methods work with versions. There's still more planned work to be done here but this is a step in the right direction.
2021-08-10 11:09:55 -04:00
end,
Sparkle: Pass all items into strategy block It's sometimes necessary to work with all the items in a Sparkle feed to be able to correctly identify the newest version but livecheck's `Sparkle` strategy only passes the `item` it views as newest into a `strategy` block. This updates the `Sparkle` strategy to optionally pass all items into a `strategy` block, so we can manipulate them (e.g., filtering, sorting). This is enabled by naming the first argument of the strategy block `items` instead of `item`. `Sparkle` `strategy` blocks where the first argument is `item` will continue to work as expected. This necessarily updates `#item_from_content` (now `items_from_content`) to return all items. I've decided to move the sorting out of `#items_from_content`, so it simply returns the items in the order they appear. If there is ever an exceptional situation where we need the original order, this will technically allow for it. The sorting has instead been moved into the `#versions_from_content` method, to maintain the existing behavior. I thought about passing the items into the `strategy` block in their original order but it feels like sorting by default is the better approach for now (partly from the perspective of maintaining existing behavior) and we can always revisit this in the future if a cask ever requires the original order. Lastly, this expands the `Sparkle` tests to increase coverage. The only untested parts are `#find_versions` (which currently requires a network request) and a couple safeguard `raise` calls when there's a `REXML::UndefinedNamespaceException` (which shouldn't be encountered unless something is broken).
2022-05-31 13:18:40 -04:00
).to eq([subbed_items[0]])
Standardize valid strategy block return types Valid `strategy` block return types currently vary between strategies. Some only accept a string whereas others accept a string or array of strings. [`strategy` blocks also accept a `nil` return (to simplify early returns) but this was already standardized across strategies.] While some strategies only identify one version by default (where a string is an appropriate return type), it could be that a strategy block identifies more than one version. In this situation, the strategy would need to be modified to accept (and work with) an array from a `strategy` block. Rather than waiting for this to become a problem, this modifies all strategies to standardize on allowing `strategy` blocks to return a string or array of strings (even if only one of these is currently used in practice). Standardizing valid return types helps to further simplify the mental model for `strategy` blocks and reduce cognitive load. This commit extracts related logic from `#find_versions` into methods like `#versions_from_content`, which is conceptually similar to `PageMatch#page_matches` (renamed to `#versions_from_content` for consistency). This allows us to write tests for the related code without having to make network requests (or stub them) at this point. In general, this also helps to better align the structure of strategies and how the various `#find_versions` methods work with versions. There's still more planned work to be done here but this is a step in the right direction.
2021-08-10 11:09:55 -04:00
Sparkle: Pass all items into strategy block It's sometimes necessary to work with all the items in a Sparkle feed to be able to correctly identify the newest version but livecheck's `Sparkle` strategy only passes the `item` it views as newest into a `strategy` block. This updates the `Sparkle` strategy to optionally pass all items into a `strategy` block, so we can manipulate them (e.g., filtering, sorting). This is enabled by naming the first argument of the strategy block `items` instead of `item`. `Sparkle` `strategy` blocks where the first argument is `item` will continue to work as expected. This necessarily updates `#item_from_content` (now `items_from_content`) to return all items. I've decided to move the sorting out of `#items_from_content`, so it simply returns the items in the order they appear. If there is ever an exceptional situation where we need the original order, this will technically allow for it. The sorting has instead been moved into the `#versions_from_content` method, to maintain the existing behavior. I thought about passing the items into the `strategy` block in their original order but it feels like sorting by default is the better approach for now (partly from the perspective of maintaining existing behavior) and we can always revisit this in the future if a cask ever requires the original order. Lastly, this expands the `Sparkle` tests to increase coverage. The only untested parts are `#find_versions` (which currently requires a network request) and a couple safeguard `raise` calls when there's a `REXML::UndefinedNamespaceException` (which shouldn't be encountered unless something is broken).
2022-05-31 13:18:40 -04:00
# Returning an array of strings from block
expect(
sparkle.versions_from_content(xml[:appcast]) do |items|
items.map { |item| item.nice_version&.sub("1", "0") }
end,
).to eq(subbed_items)
Sparkle: Provide channel information in Item Making `channel` information available in the `Item` is necessary to be able to filter out unstable items using a `strategy` block. If an item doesn't specify a channel, then it uses the default channel (this is what Sparkle itself uses for updates). Channels like `beta` are something we want to avoid for stable casks and this allows for that type of [cask-specific] filtering. It's technically possible to automatically filter out items that aren't using the default channel (i.e., `channel != nil`) in `#items_from_content` but some casks use an unstable version, so we can't do this internally. That is to say, we wouldn't be able to override internal filtering in a `strategy` block, as any omitted items wouldn't be provided to the block. Conversely, if we pass all items to a `strategy` block, we can easily filter by channel there. We haven't been filtering by channel internally and we've only found one cask where this has been a problem, so it seems fine for now.
2022-06-02 10:04:34 -04:00
expect(
sparkle.versions_from_content(xml[:beta_channel_item]) do |items|
items.find { |item| item.channel.nil? }&.nice_version
end,
).to eq([items[:appcast][1].nice_version])
Standardize valid strategy block return types Valid `strategy` block return types currently vary between strategies. Some only accept a string whereas others accept a string or array of strings. [`strategy` blocks also accept a `nil` return (to simplify early returns) but this was already standardized across strategies.] While some strategies only identify one version by default (where a string is an appropriate return type), it could be that a strategy block identifies more than one version. In this situation, the strategy would need to be modified to accept (and work with) an array from a `strategy` block. Rather than waiting for this to become a problem, this modifies all strategies to standardize on allowing `strategy` blocks to return a string or array of strings (even if only one of these is currently used in practice). Standardizing valid return types helps to further simplify the mental model for `strategy` blocks and reduce cognitive load. This commit extracts related logic from `#find_versions` into methods like `#versions_from_content`, which is conceptually similar to `PageMatch#page_matches` (renamed to `#versions_from_content` for consistency). This allows us to write tests for the related code without having to make network requests (or stub them) at this point. In general, this also helps to better align the structure of strategies and how the various `#find_versions` methods work with versions. There's still more planned work to be done here but this is a step in the right direction.
2021-08-10 11:09:55 -04:00
end
Allow regex to be passed into all strategy blocks This modifies cask-related livecheck strategies to allow passing a regex into a `strategy` block, when appropriate. These strategies were outliers that explicitly rejected a regex even if a `strategy` block was used, forcing any regex to be inlined in the `strategy` block (instead of being defined using `#regex`). With these changes, all `strategy` blocks will be able to accept a regex, further simplifying the mental model. This also helps to better align the various `find_versions` and `versions_from_*` methods across strategies.
2021-11-16 12:31:54 -05:00
it "returns an array of version strings when given content, a regex, and a block" do
Sparkle: Pass all items into strategy block It's sometimes necessary to work with all the items in a Sparkle feed to be able to correctly identify the newest version but livecheck's `Sparkle` strategy only passes the `item` it views as newest into a `strategy` block. This updates the `Sparkle` strategy to optionally pass all items into a `strategy` block, so we can manipulate them (e.g., filtering, sorting). This is enabled by naming the first argument of the strategy block `items` instead of `item`. `Sparkle` `strategy` blocks where the first argument is `item` will continue to work as expected. This necessarily updates `#item_from_content` (now `items_from_content`) to return all items. I've decided to move the sorting out of `#items_from_content`, so it simply returns the items in the order they appear. If there is ever an exceptional situation where we need the original order, this will technically allow for it. The sorting has instead been moved into the `#versions_from_content` method, to maintain the existing behavior. I thought about passing the items into the `strategy` block in their original order but it feels like sorting by default is the better approach for now (partly from the perspective of maintaining existing behavior) and we can always revisit this in the future if a cask ever requires the original order. Lastly, this expands the `Sparkle` tests to increase coverage. The only untested parts are `#find_versions` (which currently requires a network request) and a couple safeguard `raise` calls when there's a `REXML::UndefinedNamespaceException` (which shouldn't be encountered unless something is broken).
2022-05-31 13:18:40 -04:00
# Returning a string from the block
Allow regex to be passed into all strategy blocks This modifies cask-related livecheck strategies to allow passing a regex into a `strategy` block, when appropriate. These strategies were outliers that explicitly rejected a regex even if a `strategy` block was used, forcing any regex to be inlined in the `strategy` block (instead of being defined using `#regex`). With these changes, all `strategy` blocks will be able to accept a regex, further simplifying the mental model. This also helps to better align the various `find_versions` and `versions_from_*` methods across strategies.
2021-11-16 12:31:54 -05:00
expect(
Sparkle: Pass all items into strategy block It's sometimes necessary to work with all the items in a Sparkle feed to be able to correctly identify the newest version but livecheck's `Sparkle` strategy only passes the `item` it views as newest into a `strategy` block. This updates the `Sparkle` strategy to optionally pass all items into a `strategy` block, so we can manipulate them (e.g., filtering, sorting). This is enabled by naming the first argument of the strategy block `items` instead of `item`. `Sparkle` `strategy` blocks where the first argument is `item` will continue to work as expected. This necessarily updates `#item_from_content` (now `items_from_content`) to return all items. I've decided to move the sorting out of `#items_from_content`, so it simply returns the items in the order they appear. If there is ever an exceptional situation where we need the original order, this will technically allow for it. The sorting has instead been moved into the `#versions_from_content` method, to maintain the existing behavior. I thought about passing the items into the `strategy` block in their original order but it feels like sorting by default is the better approach for now (partly from the perspective of maintaining existing behavior) and we can always revisit this in the future if a cask ever requires the original order. Lastly, this expands the `Sparkle` tests to increase coverage. The only untested parts are `#find_versions` (which currently requires a network request) and a couple safeguard `raise` calls when there's a `REXML::UndefinedNamespaceException` (which shouldn't be encountered unless something is broken).
2022-05-31 13:18:40 -04:00
sparkle.versions_from_content(xml[:appcast], title_regex) do |item, regex|
Allow regex to be passed into all strategy blocks This modifies cask-related livecheck strategies to allow passing a regex into a `strategy` block, when appropriate. These strategies were outliers that explicitly rejected a regex even if a `strategy` block was used, forcing any regex to be inlined in the `strategy` block (instead of being defined using `#regex`). With these changes, all `strategy` blocks will be able to accept a regex, further simplifying the mental model. This also helps to better align the various `find_versions` and `versions_from_*` methods across strategies.
2021-11-16 12:31:54 -05:00
item.title[regex, 1]
end,
Sparkle: Pass all items into strategy block It's sometimes necessary to work with all the items in a Sparkle feed to be able to correctly identify the newest version but livecheck's `Sparkle` strategy only passes the `item` it views as newest into a `strategy` block. This updates the `Sparkle` strategy to optionally pass all items into a `strategy` block, so we can manipulate them (e.g., filtering, sorting). This is enabled by naming the first argument of the strategy block `items` instead of `item`. `Sparkle` `strategy` blocks where the first argument is `item` will continue to work as expected. This necessarily updates `#item_from_content` (now `items_from_content`) to return all items. I've decided to move the sorting out of `#items_from_content`, so it simply returns the items in the order they appear. If there is ever an exceptional situation where we need the original order, this will technically allow for it. The sorting has instead been moved into the `#versions_from_content` method, to maintain the existing behavior. I thought about passing the items into the `strategy` block in their original order but it feels like sorting by default is the better approach for now (partly from the perspective of maintaining existing behavior) and we can always revisit this in the future if a cask ever requires the original order. Lastly, this expands the `Sparkle` tests to increase coverage. The only untested parts are `#find_versions` (which currently requires a network request) and a couple safeguard `raise` calls when there's a `REXML::UndefinedNamespaceException` (which shouldn't be encountered unless something is broken).
2022-05-31 13:18:40 -04:00
).to eq([items[:appcast][0].short_version])
Allow regex to be passed into all strategy blocks This modifies cask-related livecheck strategies to allow passing a regex into a `strategy` block, when appropriate. These strategies were outliers that explicitly rejected a regex even if a `strategy` block was used, forcing any regex to be inlined in the `strategy` block (instead of being defined using `#regex`). With these changes, all `strategy` blocks will be able to accept a regex, further simplifying the mental model. This also helps to better align the various `find_versions` and `versions_from_*` methods across strategies.
2021-11-16 12:31:54 -05:00
expect(
Sparkle: Pass all items into strategy block It's sometimes necessary to work with all the items in a Sparkle feed to be able to correctly identify the newest version but livecheck's `Sparkle` strategy only passes the `item` it views as newest into a `strategy` block. This updates the `Sparkle` strategy to optionally pass all items into a `strategy` block, so we can manipulate them (e.g., filtering, sorting). This is enabled by naming the first argument of the strategy block `items` instead of `item`. `Sparkle` `strategy` blocks where the first argument is `item` will continue to work as expected. This necessarily updates `#item_from_content` (now `items_from_content`) to return all items. I've decided to move the sorting out of `#items_from_content`, so it simply returns the items in the order they appear. If there is ever an exceptional situation where we need the original order, this will technically allow for it. The sorting has instead been moved into the `#versions_from_content` method, to maintain the existing behavior. I thought about passing the items into the `strategy` block in their original order but it feels like sorting by default is the better approach for now (partly from the perspective of maintaining existing behavior) and we can always revisit this in the future if a cask ever requires the original order. Lastly, this expands the `Sparkle` tests to increase coverage. The only untested parts are `#find_versions` (which currently requires a network request) and a couple safeguard `raise` calls when there's a `REXML::UndefinedNamespaceException` (which shouldn't be encountered unless something is broken).
2022-05-31 13:18:40 -04:00
sparkle.versions_from_content(xml[:appcast], title_regex) do |items, regex|
next if (item = items[0]).blank?
match = item&.title&.match(regex)
next if match.blank?
"#{match[1]},#{item.version}"
end,
).to eq(["#{items[:appcast][0].short_version},#{items[:appcast][0].version}"])
# Returning an array of strings from the block
expect(
sparkle.versions_from_content(xml[:appcast], title_regex) do |item, regex|
Allow regex to be passed into all strategy blocks This modifies cask-related livecheck strategies to allow passing a regex into a `strategy` block, when appropriate. These strategies were outliers that explicitly rejected a regex even if a `strategy` block was used, forcing any regex to be inlined in the `strategy` block (instead of being defined using `#regex`). With these changes, all `strategy` blocks will be able to accept a regex, further simplifying the mental model. This also helps to better align the various `find_versions` and `versions_from_*` methods across strategies.
2021-11-16 12:31:54 -05:00
[item.title[regex, 1]]
end,
Sparkle: Pass all items into strategy block It's sometimes necessary to work with all the items in a Sparkle feed to be able to correctly identify the newest version but livecheck's `Sparkle` strategy only passes the `item` it views as newest into a `strategy` block. This updates the `Sparkle` strategy to optionally pass all items into a `strategy` block, so we can manipulate them (e.g., filtering, sorting). This is enabled by naming the first argument of the strategy block `items` instead of `item`. `Sparkle` `strategy` blocks where the first argument is `item` will continue to work as expected. This necessarily updates `#item_from_content` (now `items_from_content`) to return all items. I've decided to move the sorting out of `#items_from_content`, so it simply returns the items in the order they appear. If there is ever an exceptional situation where we need the original order, this will technically allow for it. The sorting has instead been moved into the `#versions_from_content` method, to maintain the existing behavior. I thought about passing the items into the `strategy` block in their original order but it feels like sorting by default is the better approach for now (partly from the perspective of maintaining existing behavior) and we can always revisit this in the future if a cask ever requires the original order. Lastly, this expands the `Sparkle` tests to increase coverage. The only untested parts are `#find_versions` (which currently requires a network request) and a couple safeguard `raise` calls when there's a `REXML::UndefinedNamespaceException` (which shouldn't be encountered unless something is broken).
2022-05-31 13:18:40 -04:00
).to eq([items[:appcast][0].short_version])
expect(
sparkle.versions_from_content(xml[:appcast], &:short_version),
).to eq([items[:appcast][0].short_version])
expect(
sparkle.versions_from_content(xml[:appcast], title_regex) do |items, regex|
items.map { |item| item.title[regex, 1] }
end,
).to eq(items[:appcast].map(&:short_version))
Allow regex to be passed into all strategy blocks This modifies cask-related livecheck strategies to allow passing a regex into a `strategy` block, when appropriate. These strategies were outliers that explicitly rejected a regex even if a `strategy` block was used, forcing any regex to be inlined in the `strategy` block (instead of being defined using `#regex`). With these changes, all `strategy` blocks will be able to accept a regex, further simplifying the mental model. This also helps to better align the various `find_versions` and `versions_from_*` methods across strategies.
2021-11-16 12:31:54 -05:00
end
Standardize valid strategy block return types Valid `strategy` block return types currently vary between strategies. Some only accept a string whereas others accept a string or array of strings. [`strategy` blocks also accept a `nil` return (to simplify early returns) but this was already standardized across strategies.] While some strategies only identify one version by default (where a string is an appropriate return type), it could be that a strategy block identifies more than one version. In this situation, the strategy would need to be modified to accept (and work with) an array from a `strategy` block. Rather than waiting for this to become a problem, this modifies all strategies to standardize on allowing `strategy` blocks to return a string or array of strings (even if only one of these is currently used in practice). Standardizing valid return types helps to further simplify the mental model for `strategy` blocks and reduce cognitive load. This commit extracts related logic from `#find_versions` into methods like `#versions_from_content`, which is conceptually similar to `PageMatch#page_matches` (renamed to `#versions_from_content` for consistency). This allows us to write tests for the related code without having to make network requests (or stub them) at this point. In general, this also helps to better align the structure of strategies and how the various `#find_versions` methods work with versions. There's still more planned work to be done here but this is a step in the right direction.
2021-08-10 11:09:55 -04:00
it "allows a nil return from a block" do
Sparkle: Pass all items into strategy block It's sometimes necessary to work with all the items in a Sparkle feed to be able to correctly identify the newest version but livecheck's `Sparkle` strategy only passes the `item` it views as newest into a `strategy` block. This updates the `Sparkle` strategy to optionally pass all items into a `strategy` block, so we can manipulate them (e.g., filtering, sorting). This is enabled by naming the first argument of the strategy block `items` instead of `item`. `Sparkle` `strategy` blocks where the first argument is `item` will continue to work as expected. This necessarily updates `#item_from_content` (now `items_from_content`) to return all items. I've decided to move the sorting out of `#items_from_content`, so it simply returns the items in the order they appear. If there is ever an exceptional situation where we need the original order, this will technically allow for it. The sorting has instead been moved into the `#versions_from_content` method, to maintain the existing behavior. I thought about passing the items into the `strategy` block in their original order but it feels like sorting by default is the better approach for now (partly from the perspective of maintaining existing behavior) and we can always revisit this in the future if a cask ever requires the original order. Lastly, this expands the `Sparkle` tests to increase coverage. The only untested parts are `#find_versions` (which currently requires a network request) and a couple safeguard `raise` calls when there's a `REXML::UndefinedNamespaceException` (which shouldn't be encountered unless something is broken).
2022-05-31 13:18:40 -04:00
expect(
sparkle.versions_from_content(xml[:appcast]) do |item|
_ = item # To appease `brew style` without modifying arg name
next
end,
).to eq([])
Standardize valid strategy block return types Valid `strategy` block return types currently vary between strategies. Some only accept a string whereas others accept a string or array of strings. [`strategy` blocks also accept a `nil` return (to simplify early returns) but this was already standardized across strategies.] While some strategies only identify one version by default (where a string is an appropriate return type), it could be that a strategy block identifies more than one version. In this situation, the strategy would need to be modified to accept (and work with) an array from a `strategy` block. Rather than waiting for this to become a problem, this modifies all strategies to standardize on allowing `strategy` blocks to return a string or array of strings (even if only one of these is currently used in practice). Standardizing valid return types helps to further simplify the mental model for `strategy` blocks and reduce cognitive load. This commit extracts related logic from `#find_versions` into methods like `#versions_from_content`, which is conceptually similar to `PageMatch#page_matches` (renamed to `#versions_from_content` for consistency). This allows us to write tests for the related code without having to make network requests (or stub them) at this point. In general, this also helps to better align the structure of strategies and how the various `#find_versions` methods work with versions. There's still more planned work to be done here but this is a step in the right direction.
2021-08-10 11:09:55 -04:00
end
it "errors on an invalid return type from a block" do
Sparkle: Pass all items into strategy block It's sometimes necessary to work with all the items in a Sparkle feed to be able to correctly identify the newest version but livecheck's `Sparkle` strategy only passes the `item` it views as newest into a `strategy` block. This updates the `Sparkle` strategy to optionally pass all items into a `strategy` block, so we can manipulate them (e.g., filtering, sorting). This is enabled by naming the first argument of the strategy block `items` instead of `item`. `Sparkle` `strategy` blocks where the first argument is `item` will continue to work as expected. This necessarily updates `#item_from_content` (now `items_from_content`) to return all items. I've decided to move the sorting out of `#items_from_content`, so it simply returns the items in the order they appear. If there is ever an exceptional situation where we need the original order, this will technically allow for it. The sorting has instead been moved into the `#versions_from_content` method, to maintain the existing behavior. I thought about passing the items into the `strategy` block in their original order but it feels like sorting by default is the better approach for now (partly from the perspective of maintaining existing behavior) and we can always revisit this in the future if a cask ever requires the original order. Lastly, this expands the `Sparkle` tests to increase coverage. The only untested parts are `#find_versions` (which currently requires a network request) and a couple safeguard `raise` calls when there's a `REXML::UndefinedNamespaceException` (which shouldn't be encountered unless something is broken).
2022-05-31 13:18:40 -04:00
expect {
sparkle.versions_from_content(xml[:appcast]) do |item|
_ = item # To appease `brew style` without modifying arg name
123
end
}.to raise_error(TypeError, Homebrew::Livecheck::Strategy::INVALID_BLOCK_RETURN_VALUE_MSG)
end
it "errors if the first block argument uses an unhandled name" do
expect { sparkle.versions_from_content(xml[:appcast]) { |something| something } }
.to raise_error("First argument of Sparkle `strategy` block must be `item` or `items`")
Standardize valid strategy block return types Valid `strategy` block return types currently vary between strategies. Some only accept a string whereas others accept a string or array of strings. [`strategy` blocks also accept a `nil` return (to simplify early returns) but this was already standardized across strategies.] While some strategies only identify one version by default (where a string is an appropriate return type), it could be that a strategy block identifies more than one version. In this situation, the strategy would need to be modified to accept (and work with) an array from a `strategy` block. Rather than waiting for this to become a problem, this modifies all strategies to standardize on allowing `strategy` blocks to return a string or array of strings (even if only one of these is currently used in practice). Standardizing valid return types helps to further simplify the mental model for `strategy` blocks and reduce cognitive load. This commit extracts related logic from `#find_versions` into methods like `#versions_from_content`, which is conceptually similar to `PageMatch#page_matches` (renamed to `#versions_from_content` for consistency). This allows us to write tests for the related code without having to make network requests (or stub them) at this point. In general, this also helps to better align the structure of strategies and how the various `#find_versions` methods work with versions. There's still more planned work to be done here but this is a step in the right direction.
2021-08-10 11:09:55 -04:00
end
end
Sparkle: Add test
2020-12-19 01:11:45 -05:00
end
Reference in New Issue Copy Permalink