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

Add unit test for expr_initializer.cpp #7795

Merged

Conversation

esteffin
Copy link
Contributor

@esteffin esteffin commented Jul 6, 2023

expr_initializer.cpp was not unit-tested.
Before extending expr_initializer functionalities (in #7392) this PR adds unit-tests for the nondet_initializer function.

@esteffin esteffin requested review from peterschrammel and a team July 6, 2023 17:16
@esteffin esteffin force-pushed the esteffin/expr-initializer-unit-test branch 2 times, most recently from a49341a to 87786b4 Compare July 6, 2023 17:24
@esteffin esteffin force-pushed the esteffin/expr-initializer-unit-test branch from 87786b4 to d8a5fa6 Compare July 6, 2023 17:27
@codecov
Copy link

codecov bot commented Jul 6, 2023

Codecov Report

Patch coverage: 100.00% and project coverage change: -0.08 ⚠️

Comparison is base (5650fb9) 78.59% compared to head (5646669) 78.52%.

Additional details and impacted files
@@             Coverage Diff             @@
##           develop    #7795      +/-   ##
===========================================
- Coverage    78.59%   78.52%   -0.08%     
===========================================
  Files         1696     1697       +1     
  Lines       193450   193627     +177     
===========================================
- Hits        152049   152048       -1     
- Misses       41401    41579     +178     
Impacted Files Coverage Δ
unit/util/expr_initializer.cpp 100.00% <100.00%> (ø)

... and 10 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

Copy link
Collaborator

@thomasspriggs thomasspriggs left a comment

Choose a reason for hiding this comment

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

A whole series of nitpicks and an idea here, but nothing I consider blocking. You need to add the new .cpp to the makefile before this will pass CI.

/// them the symbol_table in the environment.
static symbolt create_tag_populate_env(
const typet &type,
expr_initializer_test_environmentt &env)
Copy link
Collaborator

Choose a reason for hiding this comment

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

⛏️ Given that this function only updates the symbol table, it might be better to pass a reference to the symbol table, rather then the whole test environment.

const typet &type,
expr_initializer_test_environmentt &env)
{
const type_symbolt symbol{"my_type_symbol", type, ID_C};
Copy link
Collaborator

Choose a reason for hiding this comment

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

⛏️ If this function were to be called multiple times in the same test, then it would be inserting duplicate symbol names into the symbol table. This seems like a potential trap when maintaining these tests in future. Consider using the existing get_fresh_aux_symbol from src/util/fresh_symbol.h in order to mitigate this risk.

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.
The get_fresh_aux_symbol function will ALWAYS return a "normal" symbolt, and not a type_symbolt, so then the lookup in the namespace will fail as that requires the resolved symbolt to be a type_symbol.

{"foo", signedbv_typet{32}}, {"bar", unsignedbv_typet{16}}};
const struct_typet inner_struct_type{inner_struct_components};
const struct_union_typet::componentst struct_components{
{"fizz", bool_typet{}}, {"bar", inner_struct_type}};
Copy link
Collaborator

Choose a reason for hiding this comment

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

💡 Instead of using increasingly complex type construction code in unit tests, it might be worth considering writing the types in C and using unit/testing-utils/get_goto_model_from_c.h to build a symbol table from C source.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Perhaps next time

if(can_cast_type<c_enum_typet>(type))
{
const c_enum_tag_typet c_enum_tag_type{symbol.name};
return symbolt{"my_type_tag_symbol", c_enum_tag_type, ID_C};
Copy link
Collaborator

Choose a reason for hiding this comment

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

⛏️ I may have made similar comments before - however given that this symbol does not define a type, but rather has a type which is a tag variant, then featuring "type_tag" in the name seems misleading to me.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Removed as the function is now just returning the tag_typet.

}

TEST_CASE(
"nondet_initializer simple array_type",
Copy link
Collaborator

Choose a reason for hiding this comment

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

⛏️ It might be nice to specify the type instead of calling it simple - "nondet_initializer on fixed-size array of signed 8 bit bytes."

}

TEST_CASE(
"nondet_initializer double array_type",
Copy link
Collaborator

Choose a reason for hiding this comment

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

⛏️ "double" here could be confused with the floating point double type on first glance. I suggest using the wording "array of arrays".

const std::size_t elem_count = 3;
typet inner_array_type =
array_typet{inner_type, from_integer(elem_count, signedbv_typet{8})};
typet array_type =
Copy link
Collaborator

Choose a reason for hiding this comment

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

⛏️ If an array type has an "inner_array_type", does that make it an "outer_array_type"?

Copy link
Contributor Author

@esteffin esteffin Jul 6, 2023

Choose a reason for hiding this comment

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

Changed inner_array to sub_array_type, so now there is no "outer_array".

const auto inner_expected = array_exprt{
inner_array_values,
array_typet{
signedbv_typet{8}, from_integer(elem_count, signedbv_typet{8})}};
Copy link
Collaborator

Choose a reason for hiding this comment

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

⛏️ This could just be the inner_array_type rather than duplicating the type construction right?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Here I prefer to recreate the type explicitly as it guarantee more control.

side_effect_expr_nondett{unsignedbv_typet{16}, test.loc}};
const struct_exprt expected_inner_struct_expr{
expected_inner_struct_operands, inner_struct_type};
const exprt::operandst expected_struct_operands{
Copy link
Collaborator

Choose a reason for hiding this comment

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

⛏️ Wouldn't the "operands" of a struct just be the "fields"?

side_effect_expr_nondett{signedbv_typet{8}, test.loc}}}};
const union_typet union_type{union_components};
const auto result = nondet_initializer(union_type, test.loc, test.ns);
REQUIRE(!result.has_value());
Copy link
Collaborator

Choose a reason for hiding this comment

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

⛏️ Prefer the use of REQUIRE_FALSE( over REQUIRE(!

@esteffin esteffin force-pushed the esteffin/expr-initializer-unit-test branch from d8a5fa6 to 5646669 Compare July 6, 2023 23:56
@esteffin esteffin merged commit 6a689f3 into diffblue:develop Jul 7, 2023
34 of 35 checks passed
@esteffin esteffin deleted the esteffin/expr-initializer-unit-test branch July 7, 2023 10:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants