Byl vydán Nextcloud Hub 8. Představení novinek tohoto open source cloudového řešení také na YouTube. Vypíchnout lze Nextcloud AI Assistant 2.0.
Vyšlo Pharo 12.0, programovací jazyk a vývojové prostředí s řadou pokročilých vlastností. Krom tradiční nadílky oprav přináší nový systém správy ladících bodů, nový způsob definice tříd, prostor pro objekty, které nemusí procházet GC a mnoho dalšího.
Microsoft zveřejnil na GitHubu zdrojové kódy MS-DOSu 4.0 pod licencí MIT. Ve stejném repozitáři se nacházejí i před lety zveřejněné zdrojové k kódy MS-DOSu 1.25 a 2.0.
Canonical vydal (email, blog, YouTube) Ubuntu 24.04 LTS Noble Numbat. Přehled novinek v poznámkách k vydání a také příspěvcích na blogu: novinky v desktopu a novinky v bezpečnosti. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 10. LTS verzi.
Na YouTube je k dispozici videozáznam z včerejšího Czech Open Source Policy Forum 2024.
Fossil (Wikipedie) byl vydán ve verzi 2.24. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
Byla vydána nová stabilní verze 6.7 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 124. Přehled novinek i s náhledy v příspěvku na blogu. Vypíchnout lze Spořič paměti (Memory Saver) automaticky hibernující karty, které nebyly nějakou dobu používány nebo vylepšené Odběry (Feed Reader).
OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
Ahoj, snazim nejak rozvrhnout strukturu aplikace a zasekl jsem se na testovani. Zdrojaky aplikace mam v adresari app a unit testy v adresari test. Problem, na ktery jsem narazil je ten, ze neumim poradne zaradit testy, ktere testuji live system. Nejsem si jist jak se tomu rika - integracni testy / funkcni testy? Jak postupuju. Napisu si tridu napr. ktera vola REST api, ktere dela nejake operace a vraci JSON data. Tu tridu si vyzkousim tak, ze napisu metodu ve, ktere se vytvori instance tridy, zavola se metoda, ktera precte data, a pak se vypisou do console. Takovych prikladku mam nekolik a resim co s nimi. Nechci je zahodit, ale nechci je ani davat do unit testu, protoze pracuji s externim system a v mnoha pripadech nestahuji jen data, ale ho i meni. Dali byste takove prikladky dat do adresare "test/examples", "functionalTests", "integrationTests" nebo nejakeho jineho? Kdybych mockoval metody, pak by se testoval jen interface, ale ja potrebuju proste videt vypisy v konzoli, ze ty realne data a ze to fakt spravne komunikuje a pracuje s externim systemem, coz je pro me uzitecnejsi nez unit testy. Jak s tim ale nalozit?--debug
Dale jsem premyslel, jak zamezit tomu, aby nekdo pak takovy prikladek (test) nechtene spustil a vykonal v externim systemu nejakou operaci. Jestli je dobre treba volani metody zakomentoval a az ten kdo to bude zkouset si bude jisty ze opravdu vi co dela, tak ji odkomentuje a spusti. To je vlastne taky duvod proc uvazuju ze takovy prikladek neni test a taky proto, ze netestuje vystup, ale jen loguje do console. Diky za prip. napady... pulecCo tak pred spustenim testov zaarchivovat. ... Napisat simple README. ... Testovaci vs produkcny stroj
test/
. Pokud si to chceš dát do nějakého podadresáře, je to tvá záležitost.
Mockovat budeš muset především datové zdroje, abys vyzkoušel hraniční stavy a nerozbil sis přitom ostrá data. Abys tyto testy uchránil před nenechavci, udělej si na to testovacího uživatele, kterému se po přihlášení namockují jiné datové zdroje (resp. budou mockovány operace zápisu) a výstupní šablony s podrobným hlášením stavů a chyb.
bank = Bank()
balance = bank.getBalance()
print balance
Tento priklad ale neobsahuje zadne porovnani vysledku, co ma externi system vratit. Chybi zde assert.
Tento prikladek neni soucasti vysledne aplikace, jen umozni vyvinout spravne danou tridu. Taky je skoda, aby ji programator zahodil, az bude mit napsanou komunikaci spravne, protoze kdyz externi system (banka) udela update v API, tak programator muze pomoci tohoto prikladku, ktery si znovu spusti zjistit co se zmenilo a overit si, ze to tak opravdu je a dokumentace nelze atd.
Takze je dobre takove veci nekde uchovat - v adresari "test" nebo tedy "test/systemTests"?
Kdyz se z takoveho prilladku udela test:
test():
bank = Bank()
balance = bank.getBalance()
print balance
tak vyvojove prostredi ho bude moci spoustet. Ale to zase neni potreba, protoze neni co testovat - samotny test neobsahuje assert metodu, podle ktere by test framework poznal, jestli test probehl spravne nebo ne. Takze by to byl zase zbytecny "test". A v pripade, kdyby tento "test" obsahoval metody withdraw nebo deposit, by se mohlo stat, ze by nekdo prisel o penize. To je taky nechtene.
Kdyz ale prijde programator a bude potrebovat upravit onu tridu, kvuli toho, ze banka pridala novou metodu do sveho api (tzn. neni jeste nikde pokryta v testech), tak muze pouzit onen prikladek a otestovat si banku, co mu vraci za vysledky. Takze se musi nejak dostat k onomu prikladku.
Pujde tedy ve zdrojacich do adresare "test/systemTests" ? Nebo do neceho pojmenovaneho jako priklady pouziti? "test/examplesOfUse" ? Nebo je toto systemovy test ci integracni test? Jedna se totiz vpodstate o vyzkouseni si casti aplikace s realnym systemem - ale pravdepodobne jen pro programatory.
Aby to byl skutecny test musel by mockovat externi system, predhazovat nejake data a testovat vystup:
test():
bank = MockedBank()
balance = bank.getBalance()
print balance
assert(balance == 1000)
Jenze pak se testuje samotna trida bank. Kdyz pak prijde programator dopsat novou fnukcionalitu, tak sice vidi jak to funguje, ale nevi co realna banka vraci. Musi si napsat na zkousku realnou komunikaci, upravit test a zvuj realny test smazat.
No a ja se snazim prijit na to co je to vlastne ten realny test/priklad a kde ho zaradit v ramci zdrojaku.
Vypadá to, že chceš dělat testy systémové a akceptační, které se dělají na produkčním stroji. Často se píší v jiném jazyce a tak nevadí, když sdílí stejný adresář test/. Pokud si to chceš dát do nějakého podadresáře, je to tvá záležitost.Pokud nemůžeš při testu měnit ostrá data (= nemůžeš skoro nikdy) a chceš současně otestovat změnu dat skoro jako v ostrém provozu (= chceš skoro vždy), budeš potřebovat nějakou testovací instanci těch ostrých služeb. To už je pak na dohodě s provozovatelem, zda ji zřídí. Nemusí jít vždy o celou testovací instanci, může jít o spuštění pod speciálním testovacím uživatelem apod. V konfiguraci testů pak uvedeš spojení na tu testovací instanci a nemusíš ji mockovat. A současně nevadí, když to někdo spustí omylem, maximálně test selže protože testovací instance není dostupná.
Tiskni Sdílej: