Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Integration tests
See original GitHub issueBugs like #51 could be prevented by having tests that run against an actual Kubernetes cluster. This would catch wrong assumptions like return types of certain endpoints.
It’s a fair amount of work to get right, but I actually already have this set up for PSKubectl. It runs minikube in Travis, kubectl apply’s test resources, runs commands and then does assertions against output of kubectl -o json. Tests are written in PowerShell with Pester which makes interacting with kubectl very easy.
Alternatively we could just consider PSKubectl an external test suite of this, maybe even trigger a build on every published version from a branch. Or CI here could run the test suite of PSKubectl by cloning the GitHub repo.
Issue Analytics
- State:
- Created 5 years ago
- Reactions:1
- Comments:12 (7 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
kubectl delete --alldeletes all resources in a namespace 😃It’s fairly quick actually. Booting up Minikube takes a bit (45s), but every test is faster than you’d think. It
kubectl apply’s the resources before every test and uses e.g. a deployment of a hello world docker image withimagePullPolicy: IfNotPresent, so recreating pods takes about a second before every test.