logical feasibility and cohesiveness in testing

[undone stag]

Hello. I have a question about logical feasibility for testing. So, I have a test function which tests updating of objects Task.
General logic of testing: firstly I create such object via method - .objects.create(), then retrieve another object from test fixture, convert it to context dictionary (like payload in DRF), in transfer to POST method both initially created object and context dictionary.
Here my steps
Step 1: preliminary create connected object – TaskType, BUT I CAN’T CREATE IT WITH THE SAME NAME AS OBJECTS WHICH ARE ALREADY EXISTING IN TEXT FIXTURE (f.e., “bug”, “maintenance”)

task_type = TaskType.objects.create(
    name="Enhancement",
    depiction="Some_depiction"
)

Step 2: Create object – Task, BUT HERE I CAN CREATE IT WITH THE SAME NAME AS OBJECTS WHICH ARE ALREADY EXISTING IN TEXT FIXTURE

task = Task.objects.create(
    name="Apply security patches",
    depiction="Some depiction",
    time_constraints="2025-04-12",
    is_completed=False,
    priority="U",
    task_type=task_type
)

Step 3 – forming data and transferring them to POST method for updating

update_info_task = Task.objects.get(pk=2)

original_data = model_to_dict(update_info_task)

original_data["name"] = "Test " + original_data["name"]
original_data["priority"] = "A"
original_data["time_constraints"] = "2025-04-22"

original_data.pop("assignees")

valid_data = original_data

url = reverse("assignment_handler:task-update", kwargs={"pk": task.pk})

My main question – how can I ensure logical coherence while updating object Task, to avoid situation when on one side I CAN”T create object TaskType with the same name as objects in test fixture, but on other hand I CAN create object Task with the same name as objects in test fixture.
In other words, so that I have no logical contradictions in the test function and all actions are logical and consistent.

[inland sandal]

We have said this before, just don't use test fixtures. Create everything in your test from scratch.

[undone stag]

Regretfully I can't remove test fixtures from this project. I am supposed to use them

I understood your point and in future I won't use test fixtures at all

[inland sandal]

Who is telling you to use them?

[undone stag]

I was advised by one developer and now remorse a lot

[undone stag]

So, could you illuminate me with logic coherence in context of my question?

[inland sandal]

Are they still enforcing you to use them?

The logic coherence is to not use fixtures. That is my answer, no more no less.

[undone stag]

Well, it's my first project and I am supposed to leave them anyway so far

[inland sandal]

Is this school work or a work project?

[undone stag]

Pet project for searching first job

[inland sandal]

Then if it's a project you own completely, why can you not remove the fixtures?

[undone stag]

Because now it will be total rearrangement of project which is not on time right now

[inland sandal]

Welcome to world of professional development. There is never enough time to do all the things you want/need to do. BUT if something is blocking you from progressing then at times you just need to crack on and do the work.
Perhaps if you had switched out of fixtures when it was first mentioned, then you would be finished with your tests.

Also if it's a pet project, how can it have a time deadline associated with it?

[undone stag]

I understood, but it requires time limits in terms of get it done to apply for a job

[undone stag]

I have been polishing it for more than 7 months

But initial time target was not more than 3 months

[undone stag]

So, if you were how would you avoid above mentioned contradictions ?

[inland sandal]

Ok, so don't beat yourself up that the learning took longer than expected. Web development is hard and there is a lot to cover.

[inland sandal]

It's not something you can ever really avoid, it's a tension to manage and that exists with every codebase/project/product anyone has worked on. At least in the context of modern day capitalism

[undone stag]

In this case I can say - I am trapped, in most extent logically

It really hinder my for several days and I can't now resolve it on my own

Time is crucial for me now

More than ...

[inland sandal]

Then accept you got it wrong with fixtures, pull them out and redo the tests. Making posts here about the same thing again and again isn't going to move you forward.

We will get to the point of not answering, if you are not willing to put in the effort to follow advice or answers to questions.

[mellow lintel]

If your real question is "how do I create objects without clashing names" then use unique names. They don't have to be meaningful in tests. "Task Type 1" in your first test, "Task Type 2" in your second, etc...

[inland sandal]

Also this 👆 (which again is easier to see and manage if you don't use fixtures and they are created in the test function or class)

[mellow lintel]

Each TestCase should create its own objects as needed in its setUp function. They'll be destroyed when every test function in that test case has been executed, so independent TestCases can create whatever their own test functions need without worrying about clashes.

Individual test functions within those test cases can also create objects that they themselves need but no other functions do, you just have to remember that they won't be removed until every test function in the TestCase has been executed