Is this good practice with unit-testing? I've created unit test for the "student" CRUD operations that looks like this:

[Test]
    public void Can_Exec_CrudOps()
    {
        #region Prepare


        var account = Processor.Execute(new CreateAccount
        {
            Email = "email@example.com",
            Username = "username",
            Password = "password",
        }).Result;

        #endregion

        var student = Processor.Execute(new CreateStudent
        {
            AccountId = account.EntityID
        }).Result;

        Assert.NotNull(student);
        student.AreEqual(Processor.Execute(new GetStudent
        {
            EntityId = student.EntityID
        }).Result);
        student.AreEqual(Processor.Execute(new GetStudentByAccount
        {
            AccountId = account.EntityID
        }).Result);

        var upd_student = Processor.Execute(new UpdateStudent
        {
            EntityId = student.EntityID,
            Flags = StudentFlags.Active
        }).Result;

        Assert.NotNull(upd_student);
        upd_student.AreEqual(student);
        upd_student.Flags.AreEqual(StudentFlags.Active);

        Processor.Execute(new DeleteStudent
        {
            EntityId = student.EntityID
        });
    }


As you can see, the region #prepare contains code that will insert required data to the database for the current test to be possible. 

Is it good practice to create a single test for each CRUD operation and then call that test inside the tests that require them?

What I'm thinking about would look like this:

 [TestFixture]
public class StudentTest : OperationTest
{
    protected override IEnumerable&lt;Type&gt; ModelMappings
    {
        get
        {
            return NHMappings.EDUCATION;
        }
    }

    [Test]
    public void Can_Exec_CrudOps()
    {
        #region Prepare
        // here is what changed //
        var acc = new AccountTests();
        var acc_id=    acc.create_account();


        #endregion

        var student = Processor.Execute(new CreateStudent
        {
                        //here too//
            AccountId = acc_id
        }).Result;

        Assert.NotNull(student);
        student.AreEqual(Processor.Execute(new GetStudent
        {
            EntityId = student.EntityID
        }).Result);
        student.AreEqual(Processor.Execute(new GetStudentByAccount
        {
                        // and here//
            AccountId = acc_id
        }).Result);

        var upd_student = Processor.Execute(new UpdateStudent
        {
            EntityId = student.EntityID,
            Flags = StudentFlags.Active
        }).Result;

        Assert.NotNull(upd_student);
        upd_student.AreEqual(student);
        upd_student.Flags.AreEqual(StudentFlags.Active);

        Processor.Execute(new DeleteStudent
        {
            EntityId = student.EntityID
        });
        // and here //
        acc.deleteaccount(acc_id);
    }
}


So the point is not to write the same code over and over again.
No, I would say, and the reason for that is that you have too many asserts in your test (it does to many thinks). There should only be one reason for a test to fail. So:

Split your test into smaller ones with a more descriptive name and stick to one assert per test. By doing so it's also easier to track down why a test is failing, both in the case is the bug is in the test or in the production code.