Varför är dessa Java projekt så avancerat skrivet?

Testing utan interfaces och mocks låter... spännande.
Hur bygger man tester för hela flödet?
Genom att köra en in memory databas som man seedar med data varje gång?
Hur gör man unittester där man mockar bort saker som är överflödigt?

Eller är det så att man rent av skiter i tester när man skriver "ren, funktionell kod" ?

Ok ok, jag förstår. Men om du i denna funktion behöver lägga till något, eller ta bort något. Hur vet du då att de andra 200+ beroenden du har på funktionen fungerar som de ska utan tester? Är det då genom integrationstester enbart, själva funktionerna testas genom hela kedjan och Imperative Shell är då mockat, men allt annat live?

Förövrigt låter Functional Core och Imperative Shell som business layer och DAL. Så det verkar ju rent principiellt vara ungefär samma sak.

Det som får mina varningsklockor att ringa är att man inte testar och att "En ren funktion har inga sidoeffekter. Den tar ett argument och ger ett resultat, och den kommer alltid ge samma resultat för samma argument.", det låter som något som håller ungefär 1 vecka i ett större team, sen är det kört.

Funktionella språk är en helt annan värld, du kan inte kalla på databasen och göra en ändring inuti en funktion, så det blir konstigt att använda det ordet för en helt annan sak i java eller något annat.

Enhetstest är helt enkelt att du vill testa en klass och alla dess funktioner genom att anropa dom med given eller slumpad data och jämföra det mot det förväntade resultatet. Det hjälper framförallt vid komplexa projekt med hundratals klasser där en ändring på ett ställe kan påverka många andra, då kommer testerna (förhoppningsvis, om de är bra skrivna) upptäcka felet (ett gammal fall som ska fungera som inte längre gör det). Testerna körs vanligen så fort projektet sparas/kompileras/committas etc. Så att man upptäcker misstag så snart som möjligt.

Det finns många som förespråkar ’test-driven-design’ där man först skriver tester och sedan börjar utveckla för att matcha den förväntade, testbara, resultatet istället för att bara ’lösa problemet’ och strunta i tester.

@Entity
@Getter
@Setter
public class CalibrationLogg {
	@Id
	@GeneratedValue(strategy = GenerationType.AUTO)
	private long CID;
	
	// Comment for these calibration
	@NotNull
	private String comment;
	
	// y = S*AI + B
	private float SAI0;
	private float BAI0;
	private float SAI1;
	private float BAI1;
	private float SAI2;
	private float BAI2;
	private float SAI3;
	private float BAI3;
	
}

public interface CalibrationLoggRepository extends JpaRepository<CalibrationLogg, Long>{
	CalibrationLogg findByComment(String myComment); // Exempel
}

@Autowired
private CalibrationLoggRepository calibrationLoggRepository;

List<CalibrationLogg> helaDatabasen = calibrationLoggRepository.findAll();
List<CalibrationLogg> allaRaderSomHarRadernaHejIDatabasen = calibrationLoggRepository.findByComment("Hej");

Nu är ju det där väldigt förenklat. En verklig enterprise-applikation är väldigt sällan (aldrig?) så simpel att hela databasen endast skulle bestå av en enda tabell. Normalt sett skulle du skapa en Entity-class för varje tabell, sedan ett service-lager för manipulation av data, ett repository-lager för kommunikation mot datalagret, en controller för att hantera API-anrop från t.ex. en REST-klient o.s.v.

Sedan ska det sägas att Spring Boot och Spring Framework (som ditt exempel använder sig utav) är två skilda ting. Spring Boot kan förenklat jämföras med att du håller hela din applikationsserver i en container, vilket gör det lätt att snabbt bygga och köra din applikation utan att behöva sätta upp t.ex. en JBoss-instans och en webbserver etc.

Sedan, för att bidra till diskussionen, så bör man välja "rätt" verktyg för det jobb som ska utföras. Väljer du att programmera dina applikationer i Java (som främst är ett OOP-språk) så får du finna dig i att jobba enligt den paradigmen för att få ut full effekt av språket. Om man jobbar hårdvarunära kanske Java inte är rätt verktyg egentligen, utan där kanske C vore ett bättre val.

OOP är populärt i enterprise-världen då de problem som ska lösas enkelt kan förklaras m.h.a. objekt då det oftast är så pass abstrakt.
Nu har jag inte jobbat särskilt mycket med språk som är mer imperativa eller funktionella, men jag kan tänka mig att dessa lämpar sig bättre när det ska lösas problem som ligger närmare hårdvara då det sällan behöver vara särskilt abstrakt utan mer "pure", d.v.s. givet input A förväntas alltid output B.

Bra och tydligt skrivet!

Nästan all programmering jag gör innehåller åtminstone till viss del OOP, eftersom nästan alla språk har sådan funktionalitet i kärnan och för att göra det enklare att testa och utöka som du nämner.

Jag tror dock (om jag läser mellan raderna) att TS vet detta och gör säkert delar av detta själv också, men gillar det inte och vill få medhåll