We use DUnitX and it discovers all our silly mistakes before release

[Laurens 1]

On 9/23/2021 at 4:40 PM, Stefan Glienke said:

No, I took the state from SourceForge years ago and removed all the cruft that I did not need and refactored some things. Also due to the fragmentation of the project it was kinda hard to see what is actually the most recent one. I just learned that probably your fork is.

Correct, the fork on GitHub (https://github.com/DelphiCodeCoverage/DelphiCodeCoverage) is the most recent one.

 

On 9/23/2021 at 4:35 PM, Fr0sT.Brutal said:

The test involved my wrapper for createprocess with threads, IO pipes etc, it's somewhat complex to extract MRE. I have it in my backlog but hardly will put my hands on it in near future...

I would really appreciate if you send your example to me in a PM if you have one (or create an issue in the GitHub project) so we can fix it as soon as you put your hands on the issue.

[Dagados 0]

On 2/18/2019 at 1:12 PM, Lars Fosdal said:

Fresh code: https://github.com/VSoftTechnologies/DUnitX

Typical code that we test with DUnitX:
- value to string and string to value
- lookup functions
- generic classes

- formatters

as well as database integration tests (CRUD)

 

How do you guys use it?

How do you deal with the dependency between units in a large project? 
I have a project with hundreds of files and I'm having trouble building 
the Unit Test project and I have to add all the .pas files to be able to compile.

Edited December 15, 2023 by Dagados

[David Champion 46]

28 minutes ago, Dagados said:

I'm having trouble building  the Unit Test project and I have to add all the .pas files

Refactor the code to be loosely coupled; normally a huge amount of effort on a typical RAD created application.

[Roger Cigol 88]

This is arguably one of the other significant benefits of designing code with Unit Testing in mind. It encourages you to write loosely coupled (or better entirely self standing) modules....

52 minutes ago, David Champion said:

Refactor the code to be loosely coupled; normally a huge amount of effort on a typical RAD created application

If you are dealing with legacy code this might be the case - but that doesn't mean that it is not worth effort. If you intend to keep the code live and supported for the future it almost certainly IS worth refactoring.

[Der schöne Günther 306]

4 hours ago, Dagados said:

How do you deal with the dependency between units in a large project? 

It's certainly not going to be trivial, but surely worth it. Been there, done that.

 

A highly recommended read on the matter is

"Working effectively with Legacy Code"

 

Quote

The topics covered include

• Understanding the mechanics of software change: adding features, fixing bugs, improving design, optimizing performance
• Getting legacy code into a test harness
• Writing tests that protect you against introducing new problems

 

[Stefan Glienke 1901]

On 12/15/2023 at 12:06 PM, David Champion said:

Refactor the code to be loosely coupled; normally a huge amount of effort on a typical RAD created application.

The irony about this is that to build a RAD application you are using components that are by design loosely coupled and more or less easily testable in isolation. The issue starts with non-UI-related code written directly into UI control event handlers and accessing global states such as these global form variables. If one would write their RAD application also in a component-driven architecture, things would be way easier - but slapping code into event handlers is quick at first and a nightmare to maintain later.

[David Champion 46]

This is a very good point, that the component-driven architecture is more than adequate to product loosely couple code.

This has troubled me for many years.

 

Most of the time I head off in the direction of developing/refactoring around interfaces and end up with an interface oriented-design.

So many small interfaces, so loosely coupled, that dependency injection using Spring4D is an obvious choice.

 

It works for me but the end result is far removed from the tooling support given by the IDE for components.

Sometimes the interface design is clumsy and not as dedicated, short and succinct as it should be, closer to a class declaration.

I often end up with an unnecessary abstraction where a more concrete implementation as a component would do just fine.

 

Perhaps if the VCL had a different way of producing components that avoided the deep class hierarchies and used more composition there would not be this apparent tension.