I would argue that determining if your user is active or not is a critical feature to an application. That single method is likely used in middleware, filtering queries and probably some other things. I would want to have test coverage for that. With the test not depending on a database and being only 2 lines of code, there is much more to gain than to lose here IMO.
As you said, it may become more complex down the road. The fact that you are thinking this method might change is another reason why I would test it. I would want to know that any refactoring I do doesn't break this method.
I tend not to unit test things where I'm doing something like you've got :
$model = new Model(['property' => 'X']);
$this->assertEquals('X', $model->property);
But I will make sure and test the logic/functionality through "higher level" tests, so covered by stuff like :
function test_a_user_can_be_marked_inactive()
{
// whether $this->visit()->check('is_inactive') style or eventing or whatever
$this->assertTrue($user->isInactive());
}
function test_a_user_cant_login_if_marked_inactive()
{
// whatever
}
function test_a_new_user_is_marked_as_active()
{
// create a new user via your actual app
$this->assertFalse($user->isInactive());
}
That kind of thing anyway... :-) I think I'd only write a more focussed test if the isActive() function was going to get more complex. Ie, "I need to add logic to isActive() so I'll write a test first" rather than "I might one day add logic to isActive() so I'll write a test now".