-
Notifications
You must be signed in to change notification settings - Fork 325
Automated Testing
Martin Weinelt edited this page Feb 19, 2018
·
1 revision
Testing Gluon becomes harder with each new feature. Therefore, automated testing. This should be a simple make target (make test
).
A simple test scenario may look like this:
- build gluon using a fixed site for a specific target (e.g. x86 vm)
- run multiple instances of it in Qemu, connect them on a network
- check whether each instance pings
- check whether the status page works on the first of them
- check whether the mesh works
- check whether fastd works
- ...
Mögliche Tests:
- Funktioniert der Buildprozess?
- Bootet die Firmware?
- Funktionieren die Setupmodule, wie erwartet?
- Funktionieren die upgrade-scripte?
- Laufen die Services?
- Funktioniert VPN?
- Funktioniert Mesh?
- Funktioniert das Clientnetz?
- Test auf verschiedenen Hardwareplattformen
Vorhandene Ansätze/Beispiele
- Das OpenWRT-community-Repo besitzt ein automatisches Testen für PRs
- LEDE und OpenWRT bauen "nur" Branches.
- LEDE baut nicht mehr die komplette Toolchain
- https://github.com/qca/boardfarm Qualcom Boardfarm, automated Testing für OpenWRT basierte Router
- Eine Kombination aus pyexpect + pyserial + pytest mit serieller Konsole und dummen switchen reicht zum automatisierten Testing
-
Usage
-
Community
-
Development
- Device Integration
- Roadmap
- Release-life-cycle
- Protocols
- Meeting 2024/06
- Meeting 2024/05
- Meeting 2024/03
- Meeting 2024/02
- Meeting 2024/01
- Meeting 2023/06
- Meeting 2023/05
- Meetup-CCCamp
- Meeting 2023/04
- Meeting 2023/03
- Meeting 2023/02
- Meeting 2023/01
- Meeting 2022/06
- Meeting 2022/05
- Meeting 2022/04
- Meeting 2022/03
- Meeting 2022/02
- Meeting 2022/01
- Meeting 2021/01
- Meeting 2019/01
- Meeting 2018/03
- Meeting 2018/02
- Meeting 2018/01
- Meeting 2017/01
- Concepts
- Release Process
-
Debugging