Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
lldb/unittests/Process/Utility/DynamicRegisterInfoTest.cpp | ||
---|---|---|
24 | It would be better to create a fixture class, and make this a member variable of that class. If this ends up used from two tests, it will begin returning different values depending on the order of tests, whether they are run standalone, etc. |
Made fixture class. Now you made me think of adding a helper method to test register properties too.
Create a helper class and move adding regs there. Add a helper function to assert on registers.
In general, I'd prefer to avoid adding new methods to the class under test, and save subclassing for the cases where it's impossible to do things otherwise (abstract class, visibility restrictions (although that often means you're not testing what you should be)). These things could live inside an gtest fixture (subclass of testing::Test), which could have a DynamicRegisterInfo member if needed.
lldb/unittests/Process/Utility/DynamicRegisterInfoTest.cpp | ||
---|---|---|
52–53 | Maybe use SCOPED_TRACE instead? | |
62–94 | I'd probably write a helper function to convert the register lists to a vector, and then have gtest compare the vectors: std::vector<uint32_t> to_vector(uint32_t *regs) { std::vector<uint32_t> result; if (regs) { while(*regs != LLDB_INVALID_REGNUM) result.push_back(*regs++); } return result; } ... ASSERT_THAT(to_vector(info->value_regs), value_regs); |
It would be better to create a fixture class, and make this a member variable of that class. If this ends up used from two tests, it will begin returning different values depending on the order of tests, whether they are run standalone, etc.